Вышла статья "Архитектура и реализация btrfs (http://www.filesystems.nm.ru/my/btrfs.pdf)" (PDF, 360Кб). Рассмотрены дисковая структура, базовые алгоритмы, основы администрирования.URL: http://www.filesystems.nm.ru/my/btrfs.pdf
Новость: http://www.opennet.me/opennews/art.shtml?num=17540
Сложнейшие велосипеды с турбонаддувом.ФС довольно интересная и перспективная, однако о практическом применении речь пока не идёт. Думаю, что простота во многих случаях - гарант надёжности и скорости, фичастость, как правило, ухудшает оба качества.
Простые и надежные уже существуют. Сейчас потребность в фичастых и очень надежных.
Вот вот. Даже reiser4, еще каких-то пару лет назад казавшаяся очень перспективной, теперь совершенно заурядна на фоне ZFS и btrfs. Да. Нужны фичастые и надежные. Другие уже просто не поднимутся.
>Вот вот. Даже reiser4, еще каких-то пару лет назад казавшаяся очень перспективной,
>теперь совершенно заурядна на фоне ZFS и btrfs.А что, у них плагины для сжатия\шифрования и прочее вот так штатно задуманы?У рейзера свои сильные стороны, вот только пока все это до ума доведут - можно успеть поседеть :\
zfs - сжатие да, шифрование здесь http://www.opensolaris.org/os/project/zfs-crypto/
про btrfs - не слышал...
>zfs - сжатие да, шифрование здесь http://www.opensolaris.org/os/project/zfs-crypto/У рейзера все это - навернутая плагинная архитектура.То есть в принципе модуль сжатия и шифрования можно в идеале выбрать.Вот только есть опасения что я поседеть успею пока Namesys успеет отладить все эти навороты до юзабельного состояния.
>про btrfs - не слышал...
Где-то сбоку прикрутить ни сжатие ни шифрование не вопрос.Уж шифрование тома сделать не вопрос.Сжатие... ну как минимум есть fuse файловые системы которые по архивам шарятся.Дело в том что у рейзера это не где-то сбоку а штатно.Вот только пока они там все глюки выловят думаю пройдет немеряно времени.
>Вот только есть опасения что я поседеть успею пока Namesys успеет отладить все эти навороты до юзабельного состояния.в том то и дело. от btrfs я жду развития гораздо быстрее.
... может и не рав, но и по структуре она более логична и замечательно на линух ложится (собственно и в pdf-ке об этом)
>Где-то сбоку прикрутить ни сжатие ни шифрование не вопрос.Уж шифрование тома сделать не вопрос.Сжатие...да. собственно также, как и в ext. даже одним механизмом можно... в ядре всё что надо есть.
плохо то, что до релиза долго. и сейчас развитие как-то приостановилось.. я слежу за сырцами... непонятно.
>в том то и дело. от btrfs я жду развития гораздо быстрее.Ну и плюшек типа плагинов для сжатия\шифрования там вроде нет.Впрочем и без них будет неплохо на практике.Кому надо шифрование и другими методами заюзают а емкость современных HDD такова что сжатие вообще нечасто юзают нынче.Даже на том же NTFS.
>... может и не рав, но и по структуре она более логична
>и замечательно на линух ложится (собственно и в pdf-ке об этом)Вообще хорошая ФС.Учтя что ее только делать начали в 2007 а в 2008 уже как-то ездит - думаю что ее быстро до ума доведут.Оракль после этого явно не выглядит халявщиком который просто спер рхел ;)
Одно не нравится - конечно скорость да, но то что там написано про SSD - написано без учета их лимитов по перезаписям.То есть если в пуле будет SSD, убьется он довольно шустро.
>да. собственно также, как и в ext. даже одним механизмом можно... в
>ядре всё что надо есть.В ext3 так и не сделали сжатие на уровне ФС ;)
>плохо то, что до релиза долго.
Такие проекты быстро не делаются.Вообще.Даже после того как все вроде бы готово будет еще долгая отладка и обезжучка.Учтя фичность ФС это будет не быстро.
Кстати не вижу - там про добавление девайсов есть.А про изъятие чего?Такая же ж**а как с ZFS aka "билет в 1 сторону"?
думаю до "плагинов" ещё очень далеко... но не выполнимо :-)
>...Оракль после этого явно не выглядит халявщиком который просто спер рхел ;)ну она теперь на kernel.org, а на сайте oracle только ссылка...
>В ext3 так и не сделали сжатие на уровне ФС ;)о чём и хотел сказать :-)
думаю как в ext появится, то сразу же и в btrfs будет. (а иногда и наоборот)
они вообще довольно близки (пример, конвертация из ext)
и думаю, что это классно.
>Кстати не вижу - там про добавление девайсов есть.А про изъятие чего?Такая же ж**а как с ZFS aka "билет в 1 сторону"?ну что тут скажешь?
могу только заметить, что в btrfs это можно реализовать гораздо проще (и логичней), чем в zfs.
...
и вот полностью распределенное блокирование дает широкое поле для идей...
>они вообще довольно близки (пример, конвертация из ext)Конвертация там возможна только благодаря очень специальной структуре btrfs которому пофиг где именно складывать свои структуры.Даже откат на ext3 возможен.Опять же благодаря специфичному подходу btrfs.А близкого ничего нет - EXT3 довольно традиционная система, btrfs - сравнительно новая, на основе бинарных деревьев.
>могу только заметить, что в btrfs это можно реализовать гораздо проще (и
>логичней), чем в zfs.Ну насчет простоты изъятия тома я не уверен.Как минимум с него придется спихнуть все данные на остальные тома.В принципе это наверное можно.В том же духе как размазывание нагрузки на вновь подключенные тома, только наоборот - сдвинуть все данные с энного тома на остальные тома.
>и вот полностью распределенное блокирование дает широкое поле для идей...
Да вообще задумана ФС интересно.Ее авторы явно посмотрели на то как сделано в ZFS и в рейзер4 и надергали оттуда лучших идей, по идее должна получиться весьма интересная ФС =)
>Простые и надежные уже существуют. Сейчас потребность в фичастых и очень надежных.Ну и какие-же фичи вам так сильно требуются?
Мне кажется раз уж вы задали такой вопрос, то вам как раз эти фичи и не нужны (как и мне собственно). Я воспринимаю ФС, как некий прозрачный механизм хранения файлов и ничего более.
Так как очень большие, в большом количестве файлы не храню.
Те же ZFS/Reiser мне кажуться чем то отдаленным и чем -то что сложно настроить (нужны какие то комманды вводить, чего тюнить, само по себе не заведётся)
Попробуйте. Это захватывает. Честно :)) Точно также думал, пока сам не посмотрел.
>Попробуйте. Это захватывает. Честно :)) Точно также думал, пока сам не посмотрел.Попробовать-то попробуем. Может и захватит. Однако здоровый консерватизм пока что не позволит мне внедрять её везде и повсюду.
"настроить" просто
само по себе заводится
команды вводить? Хмм, да, это проблема. Мысли угадывать оно еще не научилось
Тюнить? С таким подходом к вопросу лучше не тюнить :) "по дефолту" надежнее будет
>Те же ZFS/Reiser мне кажуться чем то отдаленнымReiser 3 делается стандартным mkfs или гуйными утилями.Чего там отдаленного?А Reiser 4 пока сырой глюкастик и юзать его в продакшне и просто на свих данных я бы не стал.Как впрочем и btrfs а также и ZFS (везде кроме солярки, где она уже давно и можно рассчитывать на некоторую обезглюченность).
Почти все, что отличает ZFS от ФС предыдущего поколения. Снапшоты, клоны. Пулы хранения, множественные корни. Сжатие и шифрование данных. COW-журналирование. Производительность на хорошем железе.Я понимаю, что по отдельности почти все это уже так или иначе реализовано -- можно компоновать. Но так УДОБНО, как это сделано в ZFS -- не получится. И поверьте на слово, это много стоит.
Я тоже очень скептически высказывался о ZFS -- пока не попробовал. Даже не в деле, а просто в vmware, когда статью про нее делал. И теперь я уверен, что за ней и btrfs -- будущее. С каждым днем это понимают все больше людей.
>Я тоже очень скептически высказывался о ZFS -- пока не попробовал.Ну раз Вы её попробовали, к Вашему мнению стоит прислушаться. Надо будет тоже как-нибудь... :)
Вы хотите сказать, что с каждым днем об этом все больше людей статьи пишет? :-) Если мерять по количеству статей, то будущее за шоппингом и факингом... А если серьезно, интересны как раз реальные применения на серьезном железе под большой нагрузкой, а как раз этого на виртуалке вы проверить никак не могли. Например, ext3 спокойно держит в одной директории 10 миллионов файлов, а как там у zfs? А на многопроцессорной машине с десятком SAS-дисков в рэйде как оно?.. Так что вы пока рассуждаете о сферической ФС в вакууме.
ээ... за ссылками не ко мне -- я не сантехник. но были тут в каких-то обсуждениях очень интересные примеры по ZFS. если встречу -- обязательно приведу.
вот бывает тут некто vitek. он, наверное, лучше расскажет (сорри, если ошибаюсь). одно могу сказать точно -- и 10 миллионов файлов, и десяток SAS'ов -- это как раз то, на что ZFS расчитывалась. В отличие от ext3, кстати.
подтверждаю :-)
именно на большом количестве файлов и дисков ZFS и показывает себя во всей красе (конечно и мощность железа должна быть на уровне).
>наверное, лучше расскажетда говорить то уже и не о чем. статей по сравнению производительности уже много. найти не трудно. в общем на solaris использовать можно и нужно (а на других платформах в продакшене не использовал).
raid-z очень порадовал. (и зачем нужны аппаратные райды? :-))
(железка из 16 FS винтов по 136Gb 15000 rpm. FS - это Fibre Channel, если кто не знает)btrfs тоже очень жду. у неё есть свои плюсы (и не только лицензия - это чтоб войны не разводить). у неё мне нравиться утилиты, которые в стиле unix-way (у zfs собственно тоже не сложные, но несколько непривычный по-началу синтаксис, по моему). + btrfs можно сконвертировать из существующей ext3. и ещё ряд...
в общем винтом в 1Tb уже никого не удивишь, а эти fs как раз для таких и выше.
Больше того, zfs заточена под гетерогенные хранилища данных. Так что она отлично себя ведет не только на большом по объему количеству железа, но и большом разнообразии оного.
>Больше того, zfs заточена под гетерогенные хранилища данных. Так что она отлично
>себя ведет не только на большом по объему количеству железа, но
>и большом разнообразии оного.я так не пробовал, но верю :-)
Аноним, а скажите plz - в ZFS уже решили проблему, что когда юзер выходит за квоту он уже ничего не может удались из своего home? Ни удаленно (по NFS), ни локально...
Однако все прекрасно удаляется из рутовой консоли.
>своего home? Ни удаленно (по NFS), ни локально...Мило.Это что, юзеры будут гарантированно админу мозг выносить при юзании квот? 8-\
>Мило.Это что, юзеры будут гарантированно админу мозг выносить при юзании квот? 8-\Пока они и выносят..
Случается не каждый день, конечно, но часто. Забытый дебаг или кривой тест и превед..Проблема тянется с 2006 года.
Свежее обсуждение тут - http://www.opensolaris.org/jive/thread.jspa?messageID=269214...
> It's a known problem first mentioned on the ZFS forum in July 2006
> and remains unfixed even in Solaris 10 Update 5. The only workaround
> we found is to truncate the file using something
> like "cat /dev/null >! file" (for tcsh) since that doesn't trigger
> copy-on-write. Unfortunately, it may not be easy to train all users to do that.Но и это мнене всегда помогает, т.к. заполнение файловой системы юзера может быть и кучей мелких файлов и несколькими большими..
сори
s/FS/FC/
по данным http://ru.wikipedia.org/wiki/Zettabyte_File_System
Ограничения:
Максимальный размер файла 16 эксабайт
Максимальное количество файлов 2^48 (2 в степени 48)
Максимальная длинна имени файла 255 байт
Максимальный размер раздела 16 эксабайт
По поводу поддержки "10 миллионов файлов в одной директории" в ext3, это кто вам сказал?
по умолчанию до 32000 файлов, если залезть в ядро то до 65535 файлов.
Напиши простой скриптик и проверь. Только слишком большую цифру не ставь, время создания и удаления растет квадратично.
>Напиши простой скриптик и проверь. Только слишком большую цифру не ставь, время
>создания и удаления растет квадратично.Хм, сделали ж наконец -O dir_index?
Чтоб данные можно было положить и потом их же забрать.Это обязательно.
Крайне желательно, при прочих равных определяет выбор:
- выживаемость (мета)данных в нештатных ситуациях
- средства восстановления после серьёзного сбоя
- скорость укладки/забирания данных
+ а теперь под параллельной множественной нагрузкой
+ а теперь через год использования ФС, включая случаи забивания >90%
- скорость подъёма после конца батарейки в бесперебойнике
- минимум жёстких лимитов (вроде предопределённого количества инодов)
- поддержка ACLИспользую xfs и ext3 -- в зависимости от относительной критичности подпунктов.
>Использую xfs и ext3 -- в зависимости от относительной критичности подпунктов.Крайне интересно было бы узнать для каких целей что из них используете и чем руководствуетесь при выборе.
>>Использую xfs и ext3 -- в зависимости от относительной критичности подпунктов.
>Крайне интересно было бы узнать для каких целей что из них используете
>и чем руководствуетесь при выборе.Цели-то одинаковые -- хранение данных :)
Выбираю примерно так:
- всё, что есть риск потерять -- при возможности или оригинал, или бэкап на ext3
+ обычно сопровождается RAID1
- всё, что под тяжёлой нагрузкой, особенно одновременное r/w -- на xfs
+ может сопровождаться RAID1/10/5xfs всем хороша, но в текущих ядрах при монтировании и откате журнала после отвала питания может занулить блоки данных, которые сочтены потенциально попавшими в чужие файлы (утёкшими) -- мера безопасности, которая в сочетании с целыми метаданными ("выглядит как живой") для уникальных данных может быть гибельной. Вроде с полгода тому собирались ручку приделать, но пока это до серверов доедет...
ext3 относительно плохо ведёт себя под нагрузкой, проседает I/O и LA в потолок стреляет. В смысле "относительно xfs".
RAID0 сейчас использую крайне редко, когда-то был довольно частым признаком reiserfs (теперь в таких задачах удобней tmpfs).
PS: на всякий -- рекомендованные ссылки по созданию/администрированию RAID:
http://www.nber.org/sys-admin/linux-nas-raid.html
http://www.pythian.com/blogs/411/aligning-asm-disks-on-linux
>- всё, что под тяжёлой нагрузкой, особенно одновременное r/w -- на xfsДа, вот этим XFS реально радует.Шустрый.
лучшая из традиционных fs.
но не на руте.
зы
я ext2 юзаю.
например, на /boot :-D
>лучшая из традиционных fs.
>но не на руте.Я его использую для того для чего он рулит - хранение больших файлов к которым порой параллельный доступ, преимущественно readonly. На руте EXT3 в общем то неплох (ему бы еще повыше скорость доступа к мелочи да поменьше оверхеда на хранение инодов и было бы замечательно).
>лучшая из традиционных fs.Кстати у него и слабые места есть.
Во первых, он журналит только метаданные.Если по части сохранности данных при срубании питания в момент записи есть параноя, лучше полное журналирование как метаданных так и файлов, хоть оно и намного медленее (в разы, ибо данные файла сперва пишутся в журнал, а потом на диск).
Во вторых, в интернете есть какие-то наезды про затирание содержимого файлов нулями при внеплановых шатдаунах.Сейчас вроде основную часть проблем отловили, но все-таки.
В третьих, на некоторых видах файловых операция XFS не чемпион по скорости и\или по загрузке процессора.
В четвертых, layout данной файловой системы пришел с SGIшных систем, которые были отнюдь не х86.Поэтому прямо с нулевого смещения начинаются данные ФС.Это не проблема... пока не хоечется загружаться с этого диска, особенно если он единственный.А когда захочется, оказывается что места для загрузчика\бутсектора (который обитает ВНЕ самой по себе файловой системы) там может и не быть.Ибо с места в карьер начинаются структуры XFS.Прям с нуля.При должном желании это можно обойти.Но потенциально грабли там любизно разложены.К тому же GRUB умеет хитро лажаться при попытках себя записать на XFS.Есть там какой-то недобитый BUG...
>В четвертых, layout данной файловой системы пришел с SGIшных систем, которые были
>отнюдь не х86.Поэтому прямо с нулевого смещения начинаются данные ФС.Это не
>проблема... пока не хоечется загружаться с этого дискаДиска или раздела? Перечитайте, а то мне что-то кажется, ерунда какая-то написана. Хорошо, что мои (и ApplianceWare) корни на xfs её не слышали ;) (целый диск стараюсь под ФС не давать по другой причине -- сложно вспомнить/сообразить, что там данные, не зная этого)
>К тому же GRUB умеет хитро лажаться при попытках себя записать на XFS.
>Есть там какой-то недобитый BUG...Вот только имя этому BUG -- GRUB. Что брошенный первый, что сферический второй.
Ну хотя бы вот такие: http://blogs.sun.com/jonathan_ru/entry/%D0%BE_...
>Ну хотя бы вот такие: http://blogs.sun.com/...Там маркетологи чтоли?В этом блоге много маркетинговой воды - расписано как все будет замечательно и прочая, особенно если связаться с SUN.Коммунисты с их сказками о светлом будущем отдыхают :)
это владелец sun блог ведет :-D
online fsck, быстрый нетребовательный к памяти fsck. возможность увеличить или уменьшить размера fs добавлением и удалением дисков без выключения машины. Клево, если можно сделать несколько файловых систем на одном пуле дисков (несколько fs на одном разделе). независимость от поставщика.
> Сложнейшие велосипеды с турбонаддувом.На фоне какого-нить рейзер 4 пожалуй не предел мечтаний идиота =)
А так по моему нормальная ФС в плане соответствия ее сложности ее возможностям.> Думаю, что простота во многих случаях - гарант надёжности и скорости,
> фичастость, как правило, ухудшает оба качества.Хм... до некоторой степени согласен, НО вот например...
FAT - defective by design.Просто как топор.Но тормозно и с вагоном недостатков.Неактуален.
EXT2 - в базовом виде несложен.Только кому он в таком виде нынче нужен?Без журнала то и с тормозным проходом по каталогам.А если с журналингом, хешированием директорий и прочими фичностями - не такой уж он и простой...И так почти везде почему-то - простые фс обычно почему-то медленные и тупорылые :\
>Хм... до некоторой степени согласен, НО вот например...
>FAT - defective by design.Просто как топор.Но тормозно и с вагоном недостатков.Неактуален.Вспомнили старика, он родился во времена дискет, до сегодняшних времён даже и не думал дожить...
>EXT2 - в базовом виде несложен.Только кому он в таком виде нынче
>нужен?Без журнала то и с тормозным проходом по каталогам.А если с
>журналингом, хешированием директорий и прочими фичностями - не такой уж он
>и простой...Ну по карйней мере ничего лишнего. В нынешнем виде неплохо работает ext3fs, хотя есть более "неплохо работающие" :)
>И так почти везде почему-то - простые фс обычно почему-то медленные и
>тупорылые :\Ну просто - это не значит, что для дурака.
Все должно быть изложено так просто, как только возможно, но не проще. (Альберт Эйнштейн)
То же самое можно сказать и по отношению к ФС с поправкой на фичастость.
>Вспомнили старика, он родился во времена дискет, до сегодняшних времён даже и не думал >дожить...Почему же, xp у меня стоит на fat (даже не представляете, как здорово иногда загрузится из доса и затереть c:\windows :)
>Почему же, xp у меня стоит на fat (даже не представляете, как
>здорово иногда загрузится из доса и затереть c:\windows :)Пожалуй единственное разумное применение такой дурной конфигурации...
не только.
как бы то там ни было, но ввод-вывод у неё быстрее чем у ntfs.
т.е. выделение раздела в 1.5-2 раза больше чем ОЗУ и размещение там свопа имеет смысл (кроме безопасности:-))
>как бы то там ни было, но ввод-вывод у неё быстрее чем
>у ntfs.Очень зависит от того что, где и как.Сам по себе FAT - тормозной при работе с множеством файлов.Как именно похабный swap-раздел может и сойдет, но в линуксе для этого есть swap-разделы.Так еще быстрее и куда менее черезж*пно.Файловой системы с лишним оверхедом при этом совсем нет и так еще быстрее ;)
>Вспомнили старика, он родился во времена дискет, до сегодняшних времён даже и
>не думал дожить...Ему не дали подохнуть - 32-битным сделали :)
>Ну по карйней мере ничего лишнего.
Единственное достоинство.Зато сколько там fsck работает в случае любого незапланированного сбоя...
>В нынешнем виде неплохо работает ext3fs,
>хотя есть более "неплохо работающие" :)Ну есть.Ну ext3.Уже совсем не такой простой когда к нему приделаны всякие там журналы, хэширование директорий и прочие навороты.Зато т.к. все это где-то сбоку приделано - его минусы в виде заурядной скорости работы, ограничений навроде числа файлов в каталогах и тормозное удаление больших файлов у него никуда не пропали от этого.Реальных плюсов вижу два - отладенная годами ФС и распостраненная.Ну и гибкий выбор режимов журналирования еще - для особо параноидальных есть полный журналинг например, хоть он и тормозной.
>То же самое можно сказать и по отношению к ФС с поправкой
>на фичастость.Я тоже считаю что хорошее решение слишком сложным быть не должно.А то будет как с рейзером - задуман круто а доделать рейзер4 так и не могут до сих пор.
Лучшая ФС всех времён и народов это ext2. Я просто не понимаю зачем мне может понадобится что-то другое. Возможно огромные серверы с raid и фанатичной заботой о надёжности требуют навороченыых ФС, но на десктопе ext2 - однозначный выбор.
>Лучшая ФС всех времён и народов это ext2.Просто забейте диск на терабайт (нынче майнстрим смещается в сторону 750Гб дисков) и потом некорректно срубите питание разок.Потом расскажете, как вам время fsck у EXT2 :).Хотя-бы уж EXT3 тогда, а?И та не шедевральная.Плоховато по скорости, с рядом ограничений и устаревшим дизайном, структуры ФС занимают значительное место на диске, большие файлы удаляются долго, есть лимиты на число файлов в папке.Как системный раздел - сойдет.Как ФС для больших дисков - очень так себе.Просто на фоне остальных.
а некоторые подумают, что ext3 хуже, чем, например, utf.
а тем не менее она лучше.
она просто из ряда так называемых "традиционных" fs, и для них вовсе не плоха.просто сейчас идет "революция" fs.
и это связано не только с увеличением объема hdd (с ним тоже конечно), но и с появлением альтернатив (SSD например) и т.д....
сори
s/utf/ufs
>сори
>s/utf/ufsUFS еще более древнючий и дефективный.У них вроде даже общие корни aka какая-то допотопная миниксовская ФС.Но EXT3 до современного состояния дел прокачали немного, хоть и костыльно весьма и не устранив ряд недостатков.Но в UFS и такого нет - просто морально устаревшая ФС с древнючим дизайном в виде "как есть".
ну он тоже меняется. как ext/2/3/4. и bgfile, и log,...
...
юзается до сих пор в солярке... теперь вот и zfs :-D
>>Лучшая ФС всех времён и народов это ext2.
>Хотя-бы уж EXT3 тогда, а?Вот именно! :))
"ext3 sucks-by-design" (C) Andrew Morton
>"ext3 sucks-by-design" (C) Andrew MortonА то ext2 меньше sucks :) но для системного раздела ext3 хватит, а для остальных есть и другие ФС.... ;)
>Лучшая ФС всех времён и народов это ext2.Это если ничего нет, ничего не нужно и всё это никогда не падает по питанию.
>Я просто не понимаю зачем мне может понадобится что-то другое.
>Возможно огромные серверы с raid и фанатичной заботой о надёжности
>требуют навороченыых ФС, но на десктопе ext2 - однозначный выбор.Восьмилетней давности.
home:~> df
Filesystem Size Used Avail Use% Mounted on
/dev/md0 972M 345M 576M 38% /
udevfs 5.0M 160K 4.9M 4% /dev
/dev/md1 99G 55G 43G 57% /home
/dev/sdb1 10G 5.6G 4.5G 56% /usr
/dev/sda2 5.1G 712M 4.4G 14% /var
/dev/sdb6 350G 292G 59G 84% /var/ftp
/dev/sda6 350G 245G 106G 70% /media
/dev/sdc8 254G 242G 13G 96% /media/backup
/dev/shm 8.0G 338M 7.7G 5% /tmp
none 272M 0 272M 0% /dev/shmПрипоминая, сколько мог fsck'ться ext2-раздел гигабайт на тридцать, мне становится дурно при мысли о том, сколько бы впустую лопатился на порядок больший объём. Хранить рабочий MiniDV-материал на лентах не предлагать ;)
PS: для линуксового софтрейда в качестве "журнала" рекомендуется write intent bitmap, см. mdadm(8).
>Плоховато по скоростиext2 в большинстве тестов занимает первые строчки, не знаю кто придумал фигню, что эта ФС медленная.
>с рядом ограниченийвроде таких: 2 терабайта файл, 32 весь том
>как вам время fsck у EXT2Аккумуляторы у ноута, ИБП и регулярная запись на болванки нужных файлов - это реальная защита информации. Полагаться на надёжность ФС - не лучший вариант.
Вообще, судорожно хватать всё новое - основная болезнь современного человека. Очень плохо, когда люди высасывают проблему из пальца, а потом начинают её решать, изобретая тонну костылей.
Вы в общем равы (вздыхая..)но представьте себе раздел, заполненный на 90% файлами средней величины в 30kb, объемом 2000Gb...
после этого сами начнёте искать альтернативы... а может и свою fs напишите.
в линухе это не так уж и сложно. вот и помелс есть... :-D (не в обиду...)
Да чего тут спорить. Если у человека ненагруженный десктоп со сторэджом порядка 100 Gb ему действительно может хватать ext2/3 (хотя мне не очень понятно как можно мириться с такими тормозами).to Аноним: я вот не знаю, кто придумал такие тесты. Ни разу не получалось воспроизвести похожий результат. ext2 всегда была в аутсайдерах, даже при чистом umount().
Думается, весь этот разговор бесплоден, все эти темы давно перетерты в предыдущих обсуждениях, позиции сторон доказаны цифрами. Не вижу смысла дальше говорить о традиционных ФС.
Если кому-то еще не понятно -- будущее за перспективными файловыми системами -- ZFS, btrfs и их не родившимися еще последователями. Это уже поняли Sun, Oracle, FreeBSD development team и парни из Linux kernel project. С каждым днем это понимают все больше пользователей и администраторов. Прогресс, ИМХО, не остановить и консерватизм здесь бесполезен.
Да, реально есть машины и задачи, на которых ZFS/btrfs не являются необходимыми -- и так все неплохо работает. Только не стоит на основании этого утверждать, что традиционные ФС лучше и прозводительнее, а перспективные сложны и бесполезны болшинству пользователей. Это не правда, и скаждым днем в этом убезждаются все больше людей. Они производительнее, гибче, надежнее и _гораздо_ удобнее традиционных ФС. Для любых задач, но на более-менее современном железе.
>Да чего тут спорить. Если у человека ненагруженный десктоп со сторэджом порядка
>100 Gb ему действительно может хватать ext2/3Я вижу только одну проблему - майнстримовые диски нынче становятся на 750 Gb.Сколько будет чекаться забитый раздел на 750 гиг fsck-ом - даже предположить не берусь.
> С каждым днем это понимают все больше пользователей и администраторов.
А куда деваться?Если на десктопе на ширпотребных комплектующих легко можно хранить терабайт а то и больше - возникает резонное такое желание: найти какую-то адекватную управу на такой объем данных.В свете этого решения по управлению томами и т.п. уже не смотрятся оверкиллом.
Дык о том и разговор.
>ext2 в большинстве тестов занимает первые строчки,Любой ФС можно грамотно поднасрать :P
1) Берем файл на 4Gb.Стираем файл.Бенчмаркаем потребное на удаление файла время в разных FS.Где там у нас ext2?Правильно, понятно где.Она стирает такой файл несколько секунд (да, несколько секунд стирается ОДИН файл!).Десяток таких файлов будет стираться около минуты.А несчастные 40 гигов - не предел мечтаний с хардом на терабайт...
2) Кладем этак 30 000 файлов в 1 диру.Пробуем поработать с ними.Что, и правда первые строчки?А как же рейзер?Хотя нынче есть небольшой чит с хэшированием директорий но это довесок а потому некоторые противные особенности оригинального дизайна никуда не денется :).А сказав что EXT*2* вы сами запретили юзать хэшинг директорий, он тольако в EXT3 появился.Можно и без него, но на разлапистой структуре каталогов с кучей файлов традиционные каталоги много медленее структур с деревьями - там по задумке скорость работы мало зависит от числа элементов в каталоге и т.п..
3) Система сильно засирает диск своими инодами.Юзеж места на диске служебными структурами у EXT2 явно не чемпионский.Тут его XFS и JFS весьма сильно обидят.
4) EXT2 не журналирующая ФС так что при внеплановых рестартах будет fsck.На томе в сотни две гигов или крупнее - усраться можно ждать его завершения.А ext3 за счет журнала несколько медленнее.Оно и так то не быстрое, а с журналом - еще более не быстрое.>не знаю кто придумал фигню, что эта ФС медленная.
Бенчмарки ФС можно делать по разному.И в зависимости от того как их делать результат может очень сильно меняться.С перетряской лидеров в аутсайдеры и наоборот.Все определяется узкими местами, задачами и тем насколько конкретная ФС хорошо вписывается в задачи.Есть ряд usage pattern для которых энная ФС хорошо подходит.И есть ряд usage pattern для которых энная ФС подходит плохо.Для разных ФС эти usage pattern разные, у них ВСЕХ есть свои сильные и слабые стороны.Например если у вас допустим, RAID, большие файлы и все такое - удачи побить XFS по скорости чтения\записи больших файлов.И, кстати у XFS есть журналинг.Пусть и только для метаданных, но все-таки лучше чем никакого журнала вообще с сопутствующими FSCK на 2 часа.
>>с рядом ограничений
>вроде таких: 2 терабайта файл, 32 весь томЭто кстати по современным меркам означает что через всего несколько лет начнутся проблемы.Ну и лимиты типа 32000 файлов на каталог были простительны кривому фат в 1990 году.А в 2008 извините, архаизм слегка.
>>как вам время fsck у EXT2
>Аккумуляторы у ноута, ИБП и регулярная запись на болванки нужных файлов -Спасибо, я предпочитаю просто ext3 на системном разделе юзать, хоть он и чуть медленнее.Аккумуляторы и упсы это круто конечно но shit как известно happens по той или иной причине.И ждать пока у меня будут в случае чего два часа FSCKаться диски (например на домашней машине я преодолел терабайтную отметку) - увольте, это как-нибудь без меня.Разделы для увесистых но редко перезаписываемых данных - XFS там явно рулит.Особенно если с UPSом.
>это реальная защита информации. Полагаться на надёжность ФС - не лучший
>вариант.Бэкапы никто и не отменял.Я просто не понимаю на кой хрен в 2008 году пользоваться именно ext2.Если ext3 с хэшированием дир - оно вполне себе ничего для системного раздела и т.п.., в том числе и потому что код хорошо отлажен.
>изобретая тонну костылей.
Понимаете, можно и на лошадях ездить.На телеге.Но медленно и не очень удобно.Тем не менее, когда расстояния начинают измеряться тысячами километров а емкости дисков терабайтами - приходится иногда переоценивать уже существующие ценности.Да, можно сказать "нафиг мне ехать куда-то за 2000 км?Я могу в соседнее село на своей коняге сгонять!".Но это не значит что все разделяют вашу точку зрения.Вот и с хардами так же.
на редкость культурный форум!
спасибо всем!
если кого обидел - не судите строго :-)
присоединяюсь :)
А какой смысл реализовывать RAID и снапшоты в FS. Для первого есть контроллеры, для второго LVM
>А какой смысл реализовывать RAID и снапшоты в FS. Для первого есть
>контроллеры, для второго LVMЭто не просто RAID, это очень гибкий RAID :)
А снапшоты FS там могут параллельно работать как полноценные файловые системы, хотя зачем это?
>А какой смысл реализовывать RAID и снапшоты в FS. Для первого есть
>контроллеры, для второго LVMВключи моск - емнип чтоб не надо было контроллеров и лвм"а :)
>А какой смысл реализовывать RAID и снапшоты в FS. Для первого есть
>контроллеры, для второго LVMНапример, на домашнем компе можно использовать аппаратный контроллер (пусть и дорогой), но, имхо, слишком геморно. Уже сколько раз с raid-z (типа Raid5) при ковырянии внутри компа (на гарячую) отключалось одновременно 2 диска (ненадежные контакты, это как никак не серверная железяка). Резет и все дальше работает как пить дать. Для полного удовлетворения scrub-ом пройтись и все как рукой снимает. Как это все лечить на аппаратном контроллере - ума не приложу.
>А какой смысл реализовывать RAID и снапшоты в FS. Для первого есть
>контроллеры, для второго LVMRAID на уровне FS быстрее (файловая система знает что где лежит, да и перезаписываются при замене диска только нужные данные) и гибче (позволяет менять конфигурацию на лету, использовать разные диски).
Снапшоты нужны для бэкапов, апдейтов системы (которые можно откатить в случае неудачи). Удобно их использовать и для других вещей - например сборки нескольких версий программы из одних сорцов - создал файловую систему с исходниками, с нее наделал снимков и в каждом запустить make с нужными опциями.
Попробовал вчера, /home, /opt, /data сейчас живут на btrfs.
Из тех вещей хороших вещей, к которым привык в zfs, одна в btrfs есть. Могу делать snapshot'ы, могу subvolumes. В конце-концов появилась возможность иметь snapshot и откатиться к нему в любой момент когда понадобится.
Второй вещи нет и не предвидится, как я понял, а жаль: zfs может send/receive snapshot'ы, и с ключём -i send передаёт только изменённые блоки, таким образом организуя "incremental snapshots". Увы, с btrfs придётся сканировать все файлы в поисках того, что изменилось.
Так что для надёжных хранилищ и быстрых backups пока что единственная альтернатива Солярисному zfs - zfs FreeBSD или MacOS. Или, конечно, хорошие и очень дорогие storage arrays.
>Так что для надёжных хранилищ и быстрых backups пока что единственная альтернатива Солярисному zfs - zfs FreeBSD или MacOS. Или, конечно, хорошие и очень дорогие storage arrays.методики и рассчёты где? почему гугл эту хрень не использует? видимо у них мало данных хранится
>методики и рассчёты где? почему гугл эту хрень не использует? видимо у
>них мало данных хранитсяЩас все бросят и начнут на ZFS переходить. Там совсем другие маштабы и требования.
>>Так что для надёжных хранилищ и быстрых backups
>почему гугл эту хрень не использует? видимо у них мало данных хранитсяУ Гугла надёжность рализована на другом уровне: отвалился один сервер - ну и zfs с ним, а google.{ru,com} продолжает работать.
...""по самым скромным подсчетам около 200 тысяч серверов [...] Каждый момент от 40 до 80 машин кластера недоступны в сети""...
>методики и рассчёты где? почему гугл эту хрень не использует?Потому что у гугеля много сравнительно недорогих и не монструознах серверов.На линуксе, под который ZFS в нормальном виде для начала вообще нет.
> Попробовал вчера, /home, /opt, /data сейчас живут на btrfs.Мне в прошлый раз OOPSа хватило чтобы не делать таких вещей :).Надо б еще раз погонять но такого безрассудства от меня фиг дождетесь :P
>Так что для надёжных хранилищ
А в этом то качестве какие к btrfs предъявы?Ну насчет скорости снапшотов я еще понимаю но на именно надежности хранения то это не сказывается, только на времени создания бэкапа.
>Солярисному zfs - zfs FreeBSD или MacOS.
Это которые недоделаны то?Ага, хорошая альтернатива.После этого заявы советчика советующего недоделанный код про надежные хранилища выглядят каким-то понтом.Вот вы и пользуйте сырые ФС типа btrfs и zfs в бсд для ваших данных если они у вас столь неинтересные что и профукать можно.А я погодю их в продакшне юзать пока их релизом не заявят.Одно дело потестировать их а другое полномасштабно юзать.
> Так что для надёжных хранилищ и быстрых backups пока что единственная альтернативаДык ни BTRFS ни ZFS для *bsd пока как релиз не заявлени и потому альтернатива они только для тех кто хочет их потестировать :).И кстати в упомянутом документе про структуры btrfs сказано что инкрементальные снапшоты сделать не вопрос.То что их СЕЙЧАС нет - да пофиг.Все-равно ФС недоделана еще и не релизного качества.У кого-то проблемы с пониманием того что такое "находится в разработке" и "готово для использования в продакшне"?
Поигрался с обоими, хочу : ) Хочу понимаешь, чтобы ФС мне вовремя сказала - ай дарагой, что то с твоим диском не то, CRC битый попался!