думаю, что вопрос будет подниматься после освобождения рейзера. И вопрос будет — сразу хоронить, или сперва вспомнить как это, программировать на не-квантовых компах
reiserfs использовал с ядра 2.4.17 (да, ещё из тех времён), e3, e4 — как появилась.
ext-фс ни разу не помирали. Хотя бы с рутом в read-only система стартует и даже по ssh подключиться можно.
reiser3 помирала трижды (до невосстанавливаемого состояния), причём один раз был баг известный (пофикшен кажется в 2.4.18, cвязан с файлами больше 2 Гб), а два раза ФС падала сама по себе без видимых причин. А иногда, когда система не помирала насовсем, удалённо починить всё равно было нельзя — она не монтировалась, пока руками не сделаешь fsck --fix-fixable.
На третий раз — в 2006 году — я решил, что это закономерность, и забыл про неё навсегда. С тех пор у меня в линуксах ФС вообще ни разу не умирали, потому, что это ext3 или ext4.
Так что хе-хе, «вернуться в reiser3» — это наверное самый страшный из кошмаров.
рейзер сдыхал у меня два раза. один раз — мой косяк с рейдом, один раз — бедблок посреди журнала.
вот последнее её убило совсем, данные слил без проблем на винде (!!). там читалка рейзера журнал не умеет, и его просто игнорит — слилось всё, потерь в важных данных не нашел никаких.
ext4 заглючивал буквально недавно и очень неприятно — см.ниже.
еще с ext4 ноут регулярно требовал ребута — fs падала в RO из-за внутренней неконсистентности.
при ребуте fsck что-то чинило и всё работало дальше без проблем. надоело, на btrfs такого нет.
но «засыпание» диска на btrfs надоедает
Не холивара ради… Я поддерживаю исследовательское начало linux комьюнити, новые фишки это прекрасно. Но вряд ли решусь использовать в продакшене что-то кроме ext4+lvm. Имхо btrfs, zfs пока для экспериментов и торрентохранилок.
Всего-то на раздел писались бакапы. В один «прекрасный» день, места — ноль.
«du -hs .» говорит «тут файла на 25гиг». «df -h .» говорит «тут заняты все 50».
смотрю ls -la — файлов свежих нет просто половины.
размонтировал, fsck — найдена потеря, чего-то там фиксед. монтирую обратно — всё на месте, du/df сходятся.
повторялось раза три. ядра 3.2.0 и 3.4.1.
на btr худшее пока что ловил — это просадка IO до невозможного уровня.
Пользуем zfs в продакшне, правда на BSD :)
Вполне стабильно.
Есть noreturn проблемы, но они есть на всех фс (например поломка дисков в райд, при некотором стечении обстоятельств можно потерять пул).
ZFS решает рейд на уровне ФС (до сих пор не могу понять зачем этот не-UNIX-way придуман)
у ZFS снапшоты / роллбэки / бакап по-фичастей
ZFS как бы stable (на соляре), btrfs experimental всюду
о чем я и говорю. единственный плюс от такого нарушения — у рейда есть точные данные о фактической занятости блоков. но хорошо ли это? и можно ли передать эти данные более другим способом?
unix-way это четкое разделение ответственности. 1 задача решается одной утилитой и решается хорошо.
сложная задача решается суперпозицией маленьких, отлаженных утилит.
ZFS сливает в себя функции LVM, mdadm, дедупликатора, вроде как еще и drbd, еще и ФС…
в отличие от drbd оно работает через iscsi как с обычным scsi-устройством, не задумываясь, что через сеть, так что его «не сливает». drbd было бы если бы они свой сетевой протокол придумали, а не использовали iscsi
у ZFS есть множество вкусняшек.
мне нравится тот факт, что ZFS исходит из факта, что устройство может ошибаться, и дополнительно контролирует блоки данных с помощью 256-битных контрольных сумм.
Если хотите серьезный файл сервер с солидной нагрузкой — забудьте о Linux и тем более о Windows. Кстати не пробовал ZFS на FreeBSD. Говорят что она там хорошо уже работает.
Мои любимая конфигурация раскидать pool на несколько серверов зеркалом через iSCSI и получить по сути онлайн backup который содержит все данные до самого падения. А не какой-то ночной вариант.
На БСД с онлайн бекапом пока плохо (iscsi не умеет immediate mode пока что).
Но можно добиться этого с помощью HAST, правда бекап будет на уровне пулов а не самой бсд.
Виртуалки как раз кошернее на ZFS:
1) Каждая виртуалка созданная по образу это снэпшот фс эталона.
2) Zfs легко позволяет «хостить» блочные разделы внутри себя.
3) Загрузка образа эталона это zfs export | zfs import.
1) в lvm тоже есть снапшоты, и их поддерживают многие fs, вообще для вашего случая именно снапшоты необязательные. Достаточно copy on write в файловой системе.
2) любой файл в линухе через loop превращается в блочный раздел
3) исходя из вышеописанного rm,cp :)
вобщем вы придумали способ использовать zfs, но это не значит что это нельзя сделать другими средствами.
> 1) в lvm тоже есть снапшоты, и их поддерживают многие fs, вообще для вашего случая именно снапшоты необязательные. Достаточно copy on write в файловой системе.
Видел я снапшоты в LVM — не надо такого.
> 2) любой файл в линухе через loop превращается в блочный раздел
этот а тут это делается из коробки, да еще и iscsi можно экспортировать прямо из zfs. И настроить zfs можно конкретно под этот раздел. Удобнее чем в мерзком линуксе с мерзким lvm.
> вобщем вы придумали способ использовать zfs, но это не значит что это нельзя сделать другими средствами.
Увы, LVM довольно тормозная система, в которой вовсе не предусмотрена дедупликация или сжатие.
Да, я использую LVM, много где помогает. Там где мне нужны снапшоты и стабильность, там LVM + ext4.
Но при активном снапшоте производительсноть системыможет падать до минимально допустимого (ночью) уровня.
Это довольно громкое заявление «тормозная система». Кроме того я не зря написал "+ ваша любимая фс". LVM делает ровно ту работу, которая на нее возложена. Дедупликация на её уровне несколько бессмысленная не находите?
Я бы не использовать ext4 там где «нужна стабильность», так как в одном из худших сценариев, её восстановление займёт время квадратично её размеру…
> а вообще под линухом LVM+ваша любимая fs решает все задачи ZFS.
Допустим, есть софтверный RAID-5 (+ любимая ФС), с которого производится чтение данных. Как определить, что один из дисков в программном RAID-5 начинает сыпаться?
ZFS делает это очень легко и непринуждённо on-line, причём без потери данных и без вывода мусора — в случае с вашим программным RAID-5 будет отдаваться мусор, пока не сделают проверку и ребилд массива. Cыплющийся носитель в пуле ZFS будет оставаться в строю, пока до конца не «замолчит».
То есть команда «cat /proc/mdstat» проводит экспересс-диагностику массива и запускает, если обнаружен сыплющийся носитель, проверку всего массива, я правильно понял логику работы?
«zpool status» тоже показывает состояние пулов в текущий момент времени. LUN пула может быть в трёх состояниях: выключен из массива, резильверинг (обновление на нём информации) и в работе.
Ну, я поставил ZFS ради одной вещи — L2ARC. Эта штука позволяет подключать SSD-диск в качестве кэша к дисковому тому. Правда кэширование — только на чтение. Под Linux тоже есть что-то в этом духе, но не мейнлайн-ядре и с непонятной поддержкой.
Дедупликация — это, конечно, модно, но экономит только место, а не IOPS. Дедупликация хороша для виртуальных сред, но все равно проигрывает thin provisioning средствами гипервизора или блочного устройства (например, Device Mapper-а в Linux).
Компрессия тоже экономит место, и немного — IOPS, но размер экономии сильно зависит от самих данных.
Компрессия экономит IOPSы на маленьких файликах очень сильно. Compilebench показывает на btrfs+компрессия вдвое большую производительность практически всех тестов по ср. с btrfs без компрессии.
Полностью поддерживаю автора, он рассказал о том, чего в действительности важно почти всегда, но было не важно в моём случае.
У меня опыт работы с ZFS — это исключительно задача, допускающая потерю данных и баги. Если будет совсем бажить, то можно от ZFS отказаться и использовать ext4.
Конечно, вся надежда на BTRFS, но когда её приведут в удобоваримый вид совсем не ясно.
Использовал ее для той же задачи — файл сервер с некритичными данными. Сама ФС, как я понимаю, сверхстабильна, и в случае чего, можно снять диски, закинуть их на сервер с OpenIndiana и починиться. Но вот реализация конкретно для Linux не то чтобы рановата для продакшена, но должна использоваться с оговорками. Вот об оговорках я и написал ).
Надеюсь, через год можно будет внедрять в ответственных проектах. А вот когда допилять btrfs — вопрос. ZFS, по крайне мере, стабильно работает на Solaris, а btrfs стабильно пока нигде не работает.
Как я понял историю с btrfs то забойщиком по ее созданию был Oracle.
Я думаю после покупки Sun btrfs для Oracle стал неактуален. Они не позиционируют Linux как операционку для тяжелых задач и зачем им собственно делать btfrs когда они продают Solaris.
Я думаю когда они говорят что они полностью продолжат работать над Linux, то они слегка лукавят. Им необходимо будет как то их дифференцировать.
ZFS on Linux — не все так просто