автопроверки не нужны

В смысле вообще (сарказм), или для btrfs ? :-)

Кстати, попалось sudo ln -sf /bin/true /sbin/fsck.btrfs на kernel.org:
http://btrfs.wiki.kernel.org/index.php/Ubuntu_support
Про Убунту, правда, но вряд ли принципиально.

на btrfs

А раздел важный был для системы, или как ?

А раздел был корневой.

Кстати, попалось sudo ln -sf /bin/true /sbin/fsck.btrfs ...

а кое где — чуть-менее примитивно сделано:

$ cat /usr/bin/fsck.btrfs
#!/bin/sh -f
#
# Copyright (c) 2013 SUSE

# ... ... ...
# ... тут я вырезал большой коммент...
# ... ... ..

AUTO=false
while getopts ":aApy" c
do
	case $c in
	a|A|p|y)	AUTO=true;;
	esac
done
eval DEV=\${$#}
if [ ! -e $DEV ]; then
	echo "$0: $DEV does not exist"
	exit 8
fi
if $AUTO; then
	echo "$0: BTRFS file system."
else
	echo "If you wish to check the consistency of a BTRFS filesystem or"
	echo "repair a damaged filesystem, see btrfs(8) subcommand 'check'."
fi
exit 0

Что скажешь о ZOL? С ней я могу спать спокойно?

Если тебе нужен её функционал, то да. Таких жидких детских неожиданностей как с btrfs c zol точно не случится.

Таких жидких детских неожиданностей как с btrfs c zol точно не случится.

а если и сделается «неожиданность» — то врядли кто будет создавать тему на форуме "у меня всё накрылось на ZoL!"...

...ведь каждый такой ZoL-пользователь и сам знает, что шёл на большой риск.

(и предупреждаю что фразу "у меня ZoL ни разу не накрывалась" — не надо писать.. ведь тебе с таким же успехом — куча других людей напишут что у них ни разу не накрывалась стабильная версия Btrfs)

куча других людей напишут что у них ни разу не накрывалась стабильная версия Btrfs

Где эта «куча других людей» взяла стабильную версию btrfs?

ну, в современном стабильном ядре. где же ещё :)

(как у автора этой темы. но у него по какой-то причине — всё-таки накрылось)

а у многих (но не всех) людей — Btrfs — даже не накрывалась (ни разу) и +во времена, когда она относилась к разряду экспериментальных файловых систем.

впрочем найти можно и людей у которых и FAT32 не накрывалась.. тут только дело случая :) .. но я думаю таких крайней мало.. ведь FAT32 не устойчива к внезапному отключению электро-энергии (в отличии от Btrfs и других).

а вот если оборудование неисправно (плохая оперативка, перегретый\разогнанный процессор, плохие сектора на накопителе, плохой контроллер на накопителе) — то ни какая файловая система не поможет. буть даже самая надёжная! :)

Где эта «куча других людей» взяла стабильную версию btrfs ?

Где-то прошёл слух, что её объявили стабильной, начиная с 3.14 (ядра, в смысле - речь про btrfs.ko). :-)

ну, в современном стабильном ядре. где же ещё :)

Какая связь между стабильным ядром и стабильной btrfs? Посмотри ченджлоги ядра на предмет разработки btrfs, до сих пор много фиксов самого базового функционала, заявленные чёрт знает когда фичи не реализованы, поддержка raid не доделана до рабочего состояния. Это стабильная ФС?

слух, что её объявили стабильной, начиная с 3.14

Слух это конечно хорошо, но падала и глючила btrfs и на 3.17.x и на 3.18.x, дальше мне надоело следить за этим кадавром.

Какие версии ядра поддерживает zol? Могу ли я поставить Фанту на раздел с ZFS из Убунты в чруте?

Это стабильная ФС ?

Вопрос, в пределах каких фич...

но падала и глючила btrfs и на 3.17.x и на 3.18.x

В какие моменты ? В общем, сделал каталог с большим количеством логов на btrfs, ядро 3.14.36. Буду посмотреть.

В убунте 14.04 ядро 3.16.0-33 и zol отлично собирается. В fedora 21 zol работает на последних ядрах.

В какие моменты?

В 3.17.x на btrfs клейма негде ставить, проблемы от повреждения ro-снапшотов, до кернел-паник при -o compress-force. В 3.18.x большие проблемы с заменой диска в degraded raid1, рандомно иногда процедура проходит нормально, иногда крашится вся ФС.

проблемы от повреждения ro-снапшотов, до кернел-паник при -o compress-force.

Понятно. В общем, если нужна ФС для кучи файлов и без необходимости думать о количестве inode, можно попробовать пользоваться, получается. Экзотикой, а-ля снапшотами и raid в рамках ФС, можно не пользоваться пока.

да это просто гениальная фс.

без необходимости думать о количестве inode
Экзотикой, а-ля снапшотами и raid в рамках ФС, можно не пользоваться пока.

Тогда XFS замечательно подходит, зачем тебе этот кадавр?

к чему это было сказано?

к тому, что в случае поломки этой гениальной фс нужно доставать бэкапы, раз даже такой иксперт не знает. потому и check не нужен.

ну ты и клоун

монопенесуально. ты же даже обосновать ничего не можешь.

зачем тебе этот кадавр ?

Вроде как, замах на мэейнстрим. Лучше заранее приготовиться. Ну и неработающие фичи, в перспективе-то, интересны. Опять же, потери открытых файлов при случайном reset (kernel panic/power off/разное) у xfs - это притча во языцех. Про btrfs такого ещё не писали пока, кажется.

Вроде как, замах на мэейнстрим. Лучше заранее приготовиться. Ну и неработающие фичи, в перспективе-то, интересны. Опять же, потери открытых файлов при случайном reset (kernel panic/power off/разное) у xfs - это притча во языцех. Про btrfs такого ещё не писали пока, кажется.

опять же — неработающие фичи — не работают только у:

"""
King_Carlo ★★ (04.04.2015 11:45:49) очень ярый ZFS-воин — https://goo.gl/UbXE5Y | кризисный менеджер — https://goo.gl/U8F30Q
"""

у остальных людей — проблемы (с фичами) возникают с вероятностью примерно: 1 на миллион дисков.

со снапшотами — вообше проблем ни каких быть в btrfs не может . работают идеально! и отдебажены они вдоль и поперёк (в том числе read-only снапшоты). неотлажы до конца все ситуации в рейдами, тут да.

что обосновать-то? я использую btrfs на десктопе и ни разу не сталкивался с необходимостью восстанавливать данные, к чему твои слюни про икспертов, которым я никогда не назывался? какая логическая связь между качеством фс и моим знанием методов её восстановления? лол

ещё хочешь, чтобы тебе что-то обосновывали, мозгов сначала побольше нарасти, тупица

потому и check не нужен.

Wiki описывает что btrfs check --repair это «последний рубеж надежды» если другие способы восстановления файлов НЕ оказались успешными.

https://btrfs.wiki.kernel.org/index.php/Btrfsck

а сбойнуть файловая система — разумеется может! например банально из-за аппаратной ошибки (плохая ram, перегретый\разогнанный процессор, сбойный накопитель, и т д..)

очень ярый ZFS-воин — https://goo.gl/UbXE5Y

Что-то я там кое-что заметил, и аж тему ту пошевелил... :-)

Wiki описывает что btrfs check --repair это «последний рубеж надежды»
если другие способы восстановления файлов НЕ оказались успешными.

У fsck.ext2/3/4 - аналогично. Когда он на автомате не решается что-то сделать, то не делает. А если запустить руками и с -y, можно получить спецэффекты, в лучшем случае, в lost+found.

один разок я ковырялся в lost+found (от ext3) , раскидывая файлы обратно на свои места внутрь /var/lib/mysql/... :-)

потери открытых файлов при случайном reset (kernel panic/power off/разное) у xfs - это притча во языцех

Давным-давно пофикшено. XFS даже стала ФС по-умолчанию в энтерпрайзном redhat.

Про btrfs такого ещё не писали пока, кажется.

Писать уже было не на чем, комп просто окирпичивался :)

XFS даже стала ФС по-умолчанию в энтерпрайзном redhat.

А btrfs - в SuSe... Не RedHat, да, но вес имеет. Опять же, Oracle btrfs двигает...

А btrfs - в SuSe...

В SLES и SLED нет, только в OpenSUSE.

у остальных людей — проблемы (с фичами) возникают с вероятностью примерно: 1 на миллион дисков.

Отучитесь, пожалуйста, говорить за всех остальных людей!701

про сжатие в btrfs говорим, оно делается командой «btrfs defrag»

Оригинальное название команды, да...

Главное, что очень очевидное, да...

твои слюни про икспертов, которым я никогда не назывался?

а чего же тогда в «vs zfs» тредах пытаешься умничать про концепции, сущности, теперь вот и про ненужность автопроверок. и да, пока что, слюнями только ты тут брызжешь аки псина бешеная.

теперь вот и про ненужность автопроверок

Если, к примеру, автопроверка в btrfs работает в рамках работы драйвера самой ФС, и, дополнительно, никак и ничем не вызывается, то, в понятиях пользователя, она и не нужна. И это хорошо согласуется с предостережением по поводу использования «btrfs check --repair». То есть, это когда автоматом уже не вышло. Это всё в рамках предположений, правда. :-)

А в списке фич есть «Online filesystem check», правда, это в «features in development, or planned»...

Тред создан слишком поздно. Нужно было не во время, а до! Придумать цифры и спрашивать: «а почему так?».

Угадал файловую систему по названию темы.

Был сделан btrfs-convert

Даже не притрагивайся к этой утилите. Я тоже сделал вчера btrfs-convert, в результате получил неработающий fstrim и при попытках это исправить clear_cache'ом — виснущий при монтировании mount.

Хорошо, что backup'ы были.

Сделал btrfs check со всеми параметрами, что ещё можно предпринять?

Я тоже сделал. Ничего не нашло.

Добавил --repair — нашло какие-то ошибки, исправило, fstrim по-прежнему выдавал 0 bytes trimmed

Добавил опции --init-csum-tree --init-extent-tree, выдало ошибку, ничего исправлять не пожелало.

если бы ещё наутилус и долфин умели zfs показывать нативно.

в «vs zfs» тредах

эээ, што? я вообще-то отписываюсь только в btrfs-тредах, это истеричные zfs-евангелисты прибегают в каждый такой тред и пытаются задристать всех его участников, но да ладно, здесь же есть игнор

пытаешься умничать про концепции, сущности, теперь вот и про ненужность автопроверок

т.е. всё то, что я писал про отличия концепций zfs и btrfs, было для тебя умничанием? да ты реально тупица, если простейшие вещи вводят тебя в ступор -))

слюнями только ты тут брызжешь аки псина бешеная

не ты ли влез в тред с алогичным кукареканием? это риторический вопрос, лолка

и да, автопроверки не нужны

Да, кстати, снапшоты есть? https://btrfs.wiki.kernel.org/index.php/UseCases#How_do_I_defragment_many_fil...

и да, автопроверки не нужны

Да, действительно, все равно в btrfs они бесполезны

это хорошо что мы разобрались с тем кто куда и почему влез в этот тред... :)

...но если уж мы все (по своим разным причинам) тут собрались — то кто как думает по поводу дефрагментации SSD-дисков?

см. Во время дефрагментации увеличилось пространство занимаемое данными (комментарий)

есть мысли?

Ну конечно. Пространство же выделяется экстентами, значит если меньше экстентов, то будет меньше метаданных.

Да, кстати, снапшоты есть? https://btrfs.wiki...

когда делаешь конвертацию — то старый (ext4) раздел превращается в снапшот.

то есть после конвертации ext4->btrfs — остаётся как минимум 1 снапшот.

подразумевается, что пользовать должен этот снапшот удалить вручную, в случае успешной конвертации (а в случае неуспешной — всё вернуть взад).

остаётся только узнать — удалял ли автор этой темы — этот снапшот перед запуском дефрагментации..

Есть HAMMER, а остальное УГ не нужно. Особенно на линупсе, где всё время что-то глючит и отваливается

Ну конечно. Пространство же выделяется экстентами, значит если меньше экстентов, то будет меньше метаданных.

да, тоже интересная мысль! учитывая что метаданные на btrfs занимают гигобайты (нууэээ.. в зависимости от того какие файлы хранить :)).

Опция compress=zlib указывает,что ФС при записи должна сжимать данные по zip алгоритму.
Скорее всего дело в том,что ты не указал дефрагментатору опции сжатия данных,или указал,но по другому алгоритму lzo,который по идее работает быстрее но сжимает хуже.
В общем тебе надо указать -c zlib или -c lzo
Что именно без разницы,так как судя по времени работы дефрагментатор обжимает только не обжатые или перемещаемые данные.
Ну и если у тебя SSD или флешка то смысла в самой дефрагментации нету,разве что обжать не обжатое.

Дефрагментация ssd не нужна

ok, тестируем.

берем код: http://pastebin.com/tDxYXBcg

компилируем, запускаем ./a.out test

далее перед каждой операцией сбрасываем кеш echo 3 > /proc/sys/vm/drop_caches

$ pv test > /dev/null
 100MiB 0:00:00 [ 271MiB/s] [=========>] 100%

создаем такой же файл dd: $ dd if=/dev/urandom bs=1M count=100 of=test2

проверяем:

$ pv test2 > /dev/null
 100MiB 0:00:00 [ 490MiB/s] [============>] 100%

это заявленная скорость чтения для Intel 530.

как видно скорость чтения фрагментированного файла ниже раза в полтора.

Заодно обнаружилось, что btrfs filesystem defrag первый файл дефрагментирует только наполовину (проверял утилитой filefrag).