Pull to refresh

Comments 56

Спасибо, мне хватило глюков btrfs и xfs. Вернусь-ка я на свой старый добрый рейзер3…
Не в курсе какие там новости о reiser4?
Начало было очень неплохое, но как-то все заглохло…
думаю, что вопрос будет подниматься после освобождения рейзера. И вопрос будет — сразу хоронить, или сперва вспомнить как это, программировать на не-квантовых компах
Готовится следующее жертвоприношение.
в моей практике всё наоборот.

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 надоедает
мне кажется рейзер никогда не был в mainstream и теперь вообще не в фаворе.
гугл уже вроде всем объяснил, что ext4 без журнала на UPS это «нашевсио».
А что с XFS не так, если не секрет? Я пользуюсь давно только ей, никаких нареканий пока не было.
Не холивара ради… Я поддерживаю исследовательское начало linux комьюнити, новые фишки это прекрасно. Но вряд ли решусь использовать в продакшене что-то кроме ext4+lvm. Имхо btrfs, zfs пока для экспериментов и торрентохранилок.
спасибо, ext4 у меня в продакшене тоже уже сыпалось так, что я на btrfs перешел. оно стабильнее.
Чудеса. Как же ее нагнуть надо было чтобы она посыпалась? А btrfs разве еще не experimental?
Всего-то на раздел писались бакапы. В один «прекрасный» день, места — ноль.
«du -hs .» говорит «тут файла на 25гиг». «df -h .» говорит «тут заняты все 50».
смотрю ls -la — файлов свежих нет просто половины.
размонтировал, fsck — найдена потеря, чего-то там фиксед. монтирую обратно — всё на месте, du/df сходятся.

повторялось раза три. ядра 3.2.0 и 3.4.1.
на btr худшее пока что ловил — это просадка IO до невозможного уровня.
Ага, и дикие тормоза при fsync().
Пользуем zfs в продакшне, правда на BSD :)
Вполне стабильно.
Есть noreturn проблемы, но они есть на всех фс (например поломка дисков в райд, при некотором стечении обстоятельств можно потерять пул).
Сразу извиняюсь за ламерский вопрос.

Чем zfs лучше, чем btrfs? Или в каких случаях может понадобиться использовать именно zfs?
Тем что на solaris (и возможно на freebsd) она уже стабильна. Btrfs ещё не стабильна ни где.
дедупликации у Btrfs пока нету как минимум.
да там всё завтраками кормят про RAID 5,6.
а вы про дедупликацию…
ZFS решает рейд на уровне ФС (до сих пор не могу понять зачем этот не-UNIX-way придуман)
у ZFS снапшоты / роллбэки / бакап по-фичастей
ZFS как бы stable (на соляре), btrfs experimental всюду
рейд не делается на уровне ФС, поэтому ZFS и «нарушает» слои.
LVM + ФС = ZFS образно говоря
о чем я и говорю. единственный плюс от такого нарушения — у рейда есть точные данные о фактической занятости блоков. но хорошо ли это? и можно ли передать эти данные более другим способом?
не холивара ради… почему «не-UNIX-way»? что в этом плохого?
unix-way это четкое разделение ответственности. 1 задача решается одной утилитой и решается хорошо.
сложная задача решается суперпозицией маленьких, отлаженных утилит.
ZFS сливает в себя функции LVM, mdadm, дедупликатора, вроде как еще и drbd, еще и ФС…
в отличие от drbd оно работает через iscsi как с обычным scsi-устройством, не задумываясь, что через сеть, так что его «не сливает». drbd было бы если бы они свой сетевой протокол придумали, а не использовали iscsi
у ZFS есть множество вкусняшек.
мне нравится тот факт, что ZFS исходит из факта, что устройство может ошибаться, и дополнительно контролирует блоки данных с помощью 256-битных контрольных сумм.

для полной уверенности есть scrubbing
xgu.ru/wiki/ZFS
то есть производительность этой FS-переростка ниже плинтуса?
У нее крутая производительность.

Работаю с ZFS где-то с 2006 года, отличная штука.

Если хотите серьезный файл сервер с солидной нагрузкой — забудьте о Linux и тем более о Windows. Кстати не пробовал ZFS на FreeBSD. Говорят что она там хорошо уже работает.

Мои любимая конфигурация раскидать pool на несколько серверов зеркалом через iSCSI и получить по сути онлайн backup который содержит все данные до самого падения. А не какой-то ночной вариант.
На БСД с онлайн бекапом пока плохо (iscsi не умеет immediate mode пока что).
Но можно добиться этого с помощью HAST, правда бекап будет на уровне пулов а не самой бсд.
в конце не бсд, а фс.
А кто вам сказал про файл сервер? Нужен доступ к файлам из операционной системы. У автора, к примеру, сервер виртуалок, а не «файловый сервер».

а вообще под линухом LVM+ваша любимая fs решает все задачи ZFS.
Виртуалки как раз кошернее на ZFS:
1) Каждая виртуалка созданная по образу это снэпшот фс эталона.
2) Zfs легко позволяет «хостить» блочные разделы внутри себя.
3) Загрузка образа эталона это zfs export | zfs import.

Посмотрите на то как SmartOS использует ZFS.
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, но это не значит что это нельзя сделать другими средствами.

Не важно «что» важно «как»
2) это тоже «из коробки» вообщето, причем из гораздо более доступной коробки, которая ставится сразу в любом дистре :)

учитывая столько лишних лэеров в zfs, то это самое «как» с zfs получается мягко скажем «не прямым путём»…
Это в ZFS много слоев? в 97% ситуациях все будет делать утилита zfs. Это в LVM + fs надо будет использовать пять разных утилит.
Вот что значит пользователь а не разработчик… конечно в zfs внутри много слоёв, чего стоит только описанный в статье scl
Увы, LVM довольно тормозная система, в которой вовсе не предусмотрена дедупликация или сжатие.

Да, я использую LVM, много где помогает. Там где мне нужны снапшоты и стабильность, там LVM + ext4.
Но при активном снапшоте производительсноть системыможет падать до минимально допустимого (ночью) уровня.
Это довольно громкое заявление «тормозная система». Кроме того я не зря написал "+ ваша любимая фс". LVM делает ровно ту работу, которая на нее возложена. Дедупликация на её уровне несколько бессмысленная не находите?

Я бы не использовать ext4 там где «нужна стабильность», так как в одном из худших сценариев, её восстановление займёт время квадратично её размеру…
> а вообще под линухом LVM+ваша любимая fs решает все задачи ZFS.

Допустим, есть софтверный RAID-5 (+ любимая ФС), с которого производится чтение данных. Как определить, что один из дисков в программном RAID-5 начинает сыпаться?

ZFS делает это очень легко и непринуждённо on-line, причём без потери данных и без вывода мусора — в случае с вашим программным RAID-5 будет отдаваться мусор, пока не сделают проверку и ребилд массива. Cыплющийся носитель в пуле ZFS будет оставаться в строю, пока до конца не «замолчит».
Сыплющийся, но не отвалившийся от RAID-5 винчестер покажет?
У меня показывал, метил как «unchecked» и начинал авто перепроверку.
То есть команда «cat /proc/mdstat» проводит экспересс-диагностику массива и запускает, если обнаружен сыплющийся носитель, проверку всего массива, я правильно понял логику работы?
нет, комманда cat /proc/mdstat показывает содержимое прок-файла /proc/mdstat в котором в текстовом виде отображено текущее состояние массивов.
«zpool status» тоже показывает состояние пулов в текущий момент времени. LUN пула может быть в трёх состояниях: выключен из массива, резильверинг (обновление на нём информации) и в работе.
Хмм… вы спросили «как определить» я написал. Перепроверка рейда же делается автоматически если один из дисков выдал ошибку на записть.
Ну, я поставил ZFS ради одной вещи — L2ARC. Эта штука позволяет подключать SSD-диск в качестве кэша к дисковому тому. Правда кэширование — только на чтение. Под Linux тоже есть что-то в этом духе, но не мейнлайн-ядре и с непонятной поддержкой.

Дедупликация — это, конечно, модно, но экономит только место, а не IOPS. Дедупликация хороша для виртуальных сред, но все равно проигрывает thin provisioning средствами гипервизора или блочного устройства (например, Device Mapper-а в Linux).

Компрессия тоже экономит место, и немного — IOPS, но размер экономии сильно зависит от самих данных.

Так что какая ФС лучше, надо смотреть «по месту».
Там есть а-ля кэш на запись. Точнее log device.

ZIL называется. Ускоряет запись на медленные устройства.
да, L2ARC на SSD тоже используем на высоконагруженных серверах под видеостриминг, очень эффективно работает.
Компрессия экономит IOPSы на маленьких файликах очень сильно. Compilebench показывает на btrfs+компрессия вдвое большую производительность практически всех тестов по ср. с btrfs без компрессии.
Полностью поддерживаю автора, он рассказал о том, чего в действительности важно почти всегда, но было не важно в моём случае.

У меня опыт работы с ZFS — это исключительно задача, допускающая потерю данных и баги. Если будет совсем бажить, то можно от ZFS отказаться и использовать ext4.

Конечно, вся надежда на BTRFS, но когда её приведут в удобоваримый вид совсем не ясно.
Использовал ее для той же задачи — файл сервер с некритичными данными. Сама ФС, как я понимаю, сверхстабильна, и в случае чего, можно снять диски, закинуть их на сервер с OpenIndiana и починиться. Но вот реализация конкретно для Linux не то чтобы рановата для продакшена, но должна использоваться с оговорками. Вот об оговорках я и написал ).

Надеюсь, через год можно будет внедрять в ответственных проектах. А вот когда допилять btrfs — вопрос. ZFS, по крайне мере, стабильно работает на Solaris, а btrfs стабильно пока нигде не работает.
Как я понял историю с btrfs то забойщиком по ее созданию был Oracle.

Я думаю после покупки Sun btrfs для Oracle стал неактуален. Они не позиционируют Linux как операционку для тяжелых задач и зачем им собственно делать btfrs когда они продают Solaris.

Я думаю когда они говорят что они полностью продолжат работать над Linux, то они слегка лукавят. Им необходимо будет как то их дифференцировать.
Только что сейчас глянул,

говорят что портируют DTrace и Containers на Linux.

Ни слова о ZFS. Это естественно, им я думаю уже и Nexenta как гвоздь в заднице.
Sign up to leave a comment.

Articles