Linux, SSD, BTRFS и Trim
Я использую систему Linux (на основе Gentoo) с файловой системой BTRFS, установленной на SSD (Toshiba Q300 с сетью 480 ГБ). мой /etc/fstab
похоже:
UUID=14cb9b65-... swap swap defaults,noatime, 0 0
UUID=cd7d93b3-... / btrfs defaults,cache,compress=lzo,subvol=@ 0 1
UUID=cd7d93b3-... /home btrfs defaults,noatime,space_cache,compress=lzo,subvol=@home 0 2
UUID=cd7d93b3-... /Data btrfs defaults,noatime,space_cache,compress=lzo,subvol=@Data 0 2
UUID=cd7d93b3-... /mnt/rootfs btrfs defaults,noatime,space_cache,compress=lzo 0 0
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0 tmpfs /proc proc defaults 0 0
tmpfs /var/log tmpfs defaults,noatime,rw,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,rw,mode=1777 0 0
tmpfs /var/run tmpfs defaults,noatime 0 0
tmpfs /var/spool tmpfs defaults,noatime 0 0
tmpfs /var/lock tmpfs defaults,noatime 0 0
tmpfs /var/cache tmpfs defaults,noatime 0 0
tmpfs /run tmpfs defaults,noatime 0 0
sysfs /sys sysfs defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
devtmpfs /dev devtmpfs gid=5,mode=620 0 0
Раньше у меня был твердотельный накопитель Intel с 240 ГБ сети с файловой системой XFS. Когда я выполнил fstrim -v /
для той системы XFS, которую я делал ежедневно, я скорее получал сообщения вроде:
8 гигабайт урезан.
Теперь на верхнем уровне твердотельного накопителя Toshiba емкостью 480 Гбайт у меня есть несколько подразделов, таких как:
# btrfs subvolume list /mnt/rootfs
ID 264 gen 273 top level 5 path @_original_install
ID 265 gen 152 top level 5 path @home_install_ok
ID 266 gen 270 top level 5 path @_snapshot_install_ok
ID 267 gen 28504 top level 5 path @
ID 275 gen 28504 top level 5 path @home
ID 276 gen 26900 top level 5 path @Data
ID 607 gen 245 top level 5 path @_snapshot_home_20160330
ID 628 gen 3837 top level 5 path @_root_snapshot_20160402
и когда я начинаю fstrim
Команда, я получаю этот результат:
***************************************** # fstrim -v /mnt/rootfs/@ 177,3 GiB (190331097088 Bytes) getrimmt *****************************************
Почему объем усеченного пространства составляет 177 ГБ, а не 8 или 10, как на моем старом отформатированном в XFS SSD объемом 240 ГБ?
После обрезки моего SSD-накопителя Toshiba емкостью 480 ГБ сразу после первой обрезки результат практически тот же, теперь урезали 172 ГиБ. Итак: fstrim
не работает для BTRFS?
И знаете ли вы (очень) хорошее учебное пособие / веб-сайт или аналогичный, который объясняет BTRFS, в том числе, как работает неполный объем, как насчет метаданных?
Чем больше информации о последних версиях btrfs (я использую версию 4.4.1), тем лучше. Если бы по-немецки тоже было бы здорово...
И вредно ли это для SSD, при обрезке или при частой обрезке?
2 ответа
Из часто задаваемых вопросов по BTRFS Wiki:
Btrfs оптимизирован для SSD?
Существуют некоторые оптимизации для SSD-накопителей, и вы можете включить их, подключив с помощью -o ssd. Начиная с версии 2.6.31-rc1, эта опция монтирования будет включена, если Btrfs сможет обнаруживать невращающиеся хранилища. SSD станет важной частью будущего хранилища, и разработчики Btrfs планируют серьезно его настроить. Обратите внимание, что -o ssd не будет включать TRIM/ Discard.
Я вижу, ты не садишься с -o ssd
, Возможно твой btrfs-progs
не определяет его как SSD. (Это проверяет, если /sys/block/sdX/queue/rotational
это 0.)
" -o ssd
не включит TRIM/discard", вероятно, из-за чрезмерной перезаписи SSD дисков быстрее изнашиваются.
fstrim
manpage говорит:
Бег
fstrim
часто или даже используяmount -o discard
[который постоянно включает TRIM], может негативно повлиять на срок службы некачественных SSD-устройств. Для большинства настольных и серверных систем достаточная частота обрезки составляет один раз в неделю. Обратите внимание, что не все устройства поддерживают обрезку в очереди, поэтому каждая команда обрезки влечет за собой снижение производительности для всего, что еще может пытаться использовать диск в данный момент.
Кроме того, CoW (копирование при записи) BTRFS выгодно для твердотельных накопителей, сводя к минимуму ненужные перезаписи, так что TRIM на самом деле не так необходим для BTRFS. Файловые системы не-CoW на SSD должны быть включены TRIM.
Почему объем усеченного пространства составляет 177 ГБ, а не 8 или 10, как на моем старом отформатированном в XFS SSD объемом 240 ГБ?
Возможно, это связано с ssd_spread
не быть, откуда у вас будет больше свободного места с меньшим количеством фрагментов:
ssd_spread Mount -o ssd_spread более строго относится к поиску большой неиспользуемой области диска для новых выделений, которая имеет тенденцию фрагментировать свободное пространство с течением времени. Это часто быстрее на менее дорогих устройствах SSD.
Так как ваш Toshiba Q300 является SSD нижнего уровня, вы должны включить ssd_spread
опция монтирования
Fstrim не работает для BTRFS?
Оно делает. На странице настроек монтирования BTRFS написано: "Вы можете запустить fstrim
командовать периодически."
И знаете ли вы (очень) хорошее учебное пособие / веб-сайт или аналогичный, который объясняет BTRFS, в том числе, как работает неполный объем, как насчет метаданных?
Это лучший ресурс BTRFS: https://btrfs.wiki.kernel.org/
Man-страница btrfs-subvolume хороша. Так же как и подраздел Subvolumes руководства Sysadmin. btrfsQuota.py
это аккуратный скрипт для понимания размеров снимка / подобъема и метаданных.
Чем больше информации о последних версиях btrfs (я использую версию 4.4.1), тем лучше.
Последняя версия 4.5.3.
Если бы по-немецки тоже было бы здорово...
Я очень рекомендую btrbk
Скрипт Perl для использования BTRFS для автоматического резервного копирования и создания снимков. Это действительно демонстрирует мощь BTRFS. Автор, Аксель Бурри, из Цюриха, Швейцария, и, основываясь на том, что у него немецкое имя, он, вероятно, тоже знает немецкий; возможно, он мог бы указать вам на некоторые немецкие ресурсы BTRFS.
Также, выполняя поиск по WorldCat, эта книга упоминает BTRFS, но она несколько устарела (2011):
- Либел, Оливер. 2011. Linux Hochverfügbarkeit: Einsatzszenarien und Praxislösungen. [Sl]: Галилео Пресс.
Используйте udev, чтобы установить ssd на невращающийся диск.
Отредактируйте / добавьте файл с именем 10-ssd.rules (или любой другой) в /etc/udev/rules.d/ и вставьте строку, аналогичную
ACTION=="add|change", KERNEL=="sd[az]", ATTR{очередь / ротация}=="0", ATTR{очередь / планировщик}="mq-deadline" (это устанавливает ioscheduler для моего ssd to mq-deadline, ваши будут выглядеть примерно так
ДЕЙСТВИЕ == "добавить | изменить", KERNEL=="sda", ATTR{очередь / ротационный}=="0" (где sda - это ваш ssd, idk, если вы можете использовать UIDS, проверьте в руководстве правильные настройки, вы может также добавить ATTR{queue/scheduler}="mq-deadline", если ваше ядро его поддерживает, так как теперь он быстрее для ssds и mq, и теперь для каждого устройства можно выбирать обычные программы ioschedule)
Я бы использовал что-то вроде rw, lazytime, compress = zstd, ssd, space_cache = v2 в fstab, очевидно, подстраиваясь под вашу конфигурацию subvolume.
Если после перезагрузки все работает, следует указать 0 для cat / sys / block / sda / queue / вращение и mq-deadline для cat / sys / block / sda / queue / scheduler.
После этого fstrim -va должен работать на диске. Вы не должны выпускать сбросы все время, поэтому лучше добавить системный таймер, который запускает fstrim очень часто.
BTRFS имеет гораздо более высокие накладные расходы на запись секторов, чем XFS и EXT2/3/4. Я написал несколько скриптов, чтобы проверить это, вы можете получить их здесь и убедиться в этом сами.
В большинстве тестов в моих скриптах BTRFS пишет примерно в 11 раз больше, чем XFS (и в 48 раз больше, чем EXT4). Скорее всего, это связано с тем, что BTRFS работает по принципу "копировать при записи".
Вы видите в 22 раза больше обрезанных байтов по сравнению с XFS, а не в 11 раз, но давайте иметь в виду, что мои цифры - это просто тесты, а то, что вы видите, - это использование в реальном мире.
Мой совет - держите BTRFS подальше от SSD или, если вам нужны / хотите функции BTRFS, продолжайте следить за атрибутом "wear" SMART на вашем SSD и будьте готовы заменить его раньше.