Возможно я не дождался. И убил процесс. Ты ядро обновил после этого? У меня обновился только индекс с 23 на 25 (Xubuntu). Сегодня ещё разок попробую скрипт.
Скрипт не выполнен. ckap@ckap-G31M-ES2L:~$ cd /home/ckap/dos/ ckap@ckap-G31M-ES2L:~/dos$ ./cve_2016_0728 PP1 uid=1000, euid=1000 Increfing... finished increfing forking... finished forking caling revoke... uid=1000, euid=1000 $ whoami ckap $ uname -r 4.2.0-25-generic $
Всем Привет! Увеличиваем обороты. Разбираемся с Bcachefs — новой файловой системой для Linux Spoiler: Nsw Дисковая подсистема всегда была узким местом ПК. Проблема особенно обострилась с ростом вычислительной мощности, когда производительность харда фактически сводила на нет огромные возможности CPU. SSD, не имеющие движущихся частей, обеспечивали неплохую производительность в операциях чтения, однако они относитeльно дороги и имеют меньший ресурс. Неплохим решением стало использование тандема SSD + HDD, но это потребовало специального софта. Что имеем? Традиционные технологии — использование кеша в ОЗУ и RAID 0, позволяющие наращивать скорость операций ввода-вывода, — уже не устраивают из-за слишком большого объема обрабатываемых данных и повышенного требования к надежности. Возможность вынести журнал на внешний SSD-диск, например в ext4, помогает увеличить производительность ФС, но глобально это не настолько влияет на ситуацию. И хотя все oни по-прежнему распространены, технология совместного использования SSD + HDD оказалась наиболее интересной, так как позволяла нарастить производительность при относительно низкой цене. Идея в общем проста: SSD-накопители выступают в качестве кеширующего устройства к одному или нескольким медленным жестким дискам. При запросе данные сперва проверяются на наличие в кеше и, если они там есть, отдaются оттуда. Кеширование реализовано на уровне блочного устройства, что позволяет реализовать такую схему независимо от файловых систем и использовать везде, где есть необходимоcть в быстрых I/O-операциях: на рабочих станциях, серверах, в массивах хранения данных. Появились гибридные приводы, которые изначально сочетают обе технологии. Такие приводы поддерживаются Win 8.1 и выше, для Linux 3.19+ или с использованием патча. Интерес был очень высок, и в результате практически одновременно стартовали четыре проекта, имевшие сходные идеи. Dm-cache — решение, основанное на блочном устройстве device mapper и реализованное в виде модуля ядра. Зависит от модуля dm_mod.ko, появившегося в относительно новых ядрах (для старых есть патч). Может быть прозрачно подключено к любому устройству хранения, в том числе и к сетям SAN, iSCSI и AoE. Поддерживает LVM. С версии 3.9 добавлен в ядро, в дистрибутивах часто собран в виде модуля, поэтому ставится просто. Dm-cache заботится о долговечности SSD, для этого часто меняющиеся данные не записываются в кеш. В настоящее время поддерживается три политики кеширования: multiqueue, stochastic multiqueue (фактически улучшенная multiqueue, по умолчанию) и очистка. Основная проблема работы с dm-cache — это сложность настройки, ведь требуется три диска: с данными, для кеша и для метаданных кеша. Размер метаданных нужно правильно подсчитать. Поэтому его и не очень любят. Но в случае, когда запись изменений в кеше откладывается (write-back), dm-cache показывает неплохой результат. Flashcache создан в Facebook для решения проблем с масштабированием производительности InnoDB/MySQL, выпущен под лицензией GNU GPL. Реализован в виде модуля для ядра Linux (потребуется его сборка), работающего в стеке device mapper. Судя по активности на GitHub, основной код давно не обновлялся, хотя есть фиксы, устраняющие проблемы сборки с новыми ядрами третьей ветки. Не собирается в 32-битных Linux. Для использования на корневой файловой системе или LVM PV необходим модуль Dracut. Flashcache может работать с двумя SSD, собранными как RAID 0 или RAID 1. Поддерживаются четыре политики кеширования: write-back (отложенная запись, данные пишутся на SSD, затем на медленный диск через время, определенное политиками), write-through (сквозная запись, данные пишутся на HDD, а затем в кеш), write-around (данные кешируются на SSD и сразу записываются на диск) и WriteOnly (вариант write-back, при котором кешируются только входящие данные). Настройке поддаются все параметры: размер блока, объем кеш-памяти, алгоритмы вытеснения FIFO или LRU (менее используемые блоки) и многое другое. Данные можно помечать как некешируемые. EnhanceIO — форк flashcache, разрабатываемый в корпорации STEC и курируемый Дарриком Вонгом (Darrick Wong) из Oracle. Некоторые компоненты и алгоритмы полностью изменены, в результате он потребляет меньше ресурсов и в режиме параллельной записи (write-through) работает быстрее. Здесь не используется device mapper, поэтому появляется возможность подключать и отключать кеширование без остановки системы на лету. Может работать с любым устройством: диском, разделом, software RAID, RAID DAS, SAN. Реализовано три режима: read-only, write-through и write-back — и три политики замещения: random (фактически round-robin), FIFO и LRU. Планировалось включение в ядро 3.10, но пока придется собирать все самостоятельно. Все эти проекты нельзя назвать заброшенными, но и активно они не развиваются. Для flashcache и EnhanceIO потребуется пересборка ядра, а dm-cache хотя и предлагается некоторыми хостерами, но все-таки сложен. Наиболее интересен Bcache и новое решение на его основе Bcachefs. Проект Bcachefs Вначале был Bcache (block cache) — проект, запущенный в 2010 году как личный проект Кента Оверстрита (Kent Overstreet). Позже он заинтересовал Google, и некоторое время Кент продолжал развитие Bcache, работая в этой корпорации. К 2012 году Bcache уже представлял собой вполне стабильный релиз, а с версии Linux ядра 3.10 (2013 год) входит в состав ядра. Реализован, как и прочие подобные решения, в виде блочного устройства. Доступны две основные политики кеширования: write-back и write-through (по умолчанию). При write-through операция записи считается завершенной после сохранения данных на обоих дисках. Это гарантирует целостность, но снижает скорость. Дополнительно реализован так называемый readahead, когда кеш наполняется не только при записи, но и при операциях чтения. Чтобы повысить эффективность, последовательные обращения к большому объему данных не кешируются, в кеш попадают только операции случайного чтения и записи. Учитывая ограниченный ресурс, случайные операции записи преобразуются с использованием btree в последовательное заполнение накопителя. При сбросе данных на диск данные группируются с учетом минимизации перемещения головок диска. Один SSD может кешировать несколько HDD, их количество при необходимости можно менять и устанавливать гарантируемый порог I/O, чтобы избежать перегрузки SSD. Один важный момент. Чтобы нельзя было получить доступ к этим разделам и нарушить кеш, Bcache требует явного переформатирования разделов, поэтому его удобно разворачивать на чистую систему или данные предварительно необходимо заархивировать. Постепенно развивая проект, разработчики пришли к выводу, что блочное устройство содержит компоненты файловой системы, поэтому, пересмотрев подход, можно убрать один уровень и обеспечить более простое использование и управление. Так и появился Bcache File System — Bcachefs. Цель проекта — создать файловую систему, соответствующую ext4 и XFS по производительности и надежности с некоторыми особенностями Btrfs и ZFS. Пока проект официально находится в альфа-стадии, но считается достаточно стабильным. В настоящее время разработчики реализовали большинство базовых возможностей POSIX ФС, в том числе xattrs и ACL. Плюс возможность включения в раздел нескольких устройств (пока только два), репликацию (RAID), кеширование, прозрачное сжатие данных (пока только gzip) и верификацию целостности по контрольным суммам. Файловая система основана на использовании механизма copy-on-write (COW), при котором один файл могут получить несколько устройств, а изменения не приводят к перезаписи данных: новое состояние записывается в новое место, после чего меняется указатель актуального состояния. Несколько устройств могут подключаться слоями, когда более быстрый накопитель используется для кеширования данных медленного диска с нижнего слоя. Необходима оптимизация — в тестах Bcachefs уже заметно обгоняет Btrfs, но пока отстает от ext4. В будущем планируется добавить и другие атрибуты современной ФС: предварительное резервирование места (fallocate), квоты, снапшоты, SMR (Shingled Magnetic Recording) и RAW режим доступа к flash и другие. Пробуем Для тестирования Bcachefs достаточно собрать ядро (на момент написания 4.1.0) и утилиту администрирования. Проект не предоставляет архив, поэтому все необходимое (приблизительно 700 Мбайт) качаем из Git. $ sudo apt-get install kernel-package fakeroot build-essential ncurses-dev bc Сам Bcachefs находится в ветке bcache-dev, утилиты — в dev (в Ubuntu ppa:g2p/storage не подходит). $ git clone -b bcache-dev http://evilpiepirate.org/git/linux-bcache.git Собираем ядро, здесь в общем все стандартно. За основу конфигурации ядра с Bcachefs используем настройки текущего: $ cd linux-bcache $ cat /boot/config-`uname -r`>.config $ make oldconfig $ make-kpkg clean $ make-kpkg -j5 --initrd kernel_image kernel_headers Ставим получившиеся deb-пакеты: $ sudo dpkg -i linux-headers-4.1.0-bcache-10.00.Custom_amd64.deb $ sudo dpkg -i linux-image-4.1.0-bcache-10.00.Custom_amd64.deb Можем перезагружаться с новым ядром. Для настроек Bcachefs используется bcacheadm (в Bcache — make-bcache). Ставим пакеты, необходимые для сборки: $ sudo apt-get install libnih-dev libblkid-dev И собираем: $ git clone -b dev http://evilpiepirate.org/git/bcache-tools.git $ cd bcache-tools $ make $ sudo make install Теперь можем отформатировать раздел: $ sudo bcacheadm format -C /dev/sdb1 И примонтировать раздел, не забыв указать тип файловой системы: $ sudo mount -t bcache /dev/sdb1 /mnt Для включения контрольных сумм и сжатия при монтировании можно дополнительно задать -o data_checksum=crc32c,compression=gzip. Если диска два, их можно положить слоями с автоматическим кешированием между уровнями: $ sudo bcacheadm format -C /dev/sdb1 --tier 1-C /dev/sdc1 При этом слой с большей цифрой предназначен для медленных устройств. Все параметры форматирования можно узнать, введя $ bcacheadm format --help Например, возможно указать и бэкенд-устройство при помощи параметра -B: $ bcacheadm format -C /dev/sdb1 -B /dev/sdc1 Правда, такая схема пока не совсем работает. Параметр —cache-mode позволяет задать режим кеширования при форматировании. При необходимости его можно затем изменить, обратившись к /sys/fs/bcache. Утилита bcacheadm имеет тринадцать основных параметров, но пока работают не все. Например, список устройств выдаст bcacheadm list. Вывод Даже простые тесты показывают, что использование связки SSD + HDD дает существенный прирост производительности. В разных ситуациях различные решения приносят свой результат, поэтому следует ориентироваться на конкретную нагрузку и возможность простого развертывания. Bcachefs, вероятно, пока рано рекомендовать для продакшна. Но начинание весьма интересно, и главное, что, в отличие от конкурентов, проект активно развивается. Исток https://xakep.ru/2015/09/23/bcachefs-linux/
