Ресурс Phoronix провел тестирование (http://www.phoronix.com/scan.php?page=article&item=btrfs_zfs...) производительности файловых систем Btrfs, EXT4 и ZFS на обычном жестком диске и SSD-накопителе. Работа ZFS оценивалась в PC-BSD 8.1, а Btrfs и EXT4 в последней тестовой версии Ubuntu 10.10 c Linux-ядром 2.6.35. В 4 тестах (Compile Bench, Dbench, FS-Mark, Threaded I/O Tester) на SSD-накопителе EXT4 обогнала по производительности файловую систему Btrfs, работающую в режиме оптимизации для твердотельных дисков. При повторении опыта (http://www.phoronix.com/scan.php?page=news_item&px=ODQ4Nw) с более старым Linux-ядром подобного отставания Btrfs не наблюдалось.
Некоторые сторонние экспериментаторы также сообщили (http://article.gmane.org/gmane.comp.file-systems.btrfs/6353) о наличии регрессивного изменения (http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstab...) в коде Btrfs из Linux-ядра 2.6.35, уточнив, что пробл...URL: http://www.phoronix.com/scan.php?page=article&item=btrfs_zfs...
Новость: http://www.opennet.me/opennews/art.shtml?num=27573
Ext4 так просто позиции не сдаёт! На HDD Btrfs тоже не особо.
Да вообще-то btrfs довольно прилично выступает кроме некоторых моментов. И в отличие от EXT4 по сути журналит как метаданные так и данные (работают CoW-файловые систем так). А если на EXT4 полный журналинг врубить - будет довольно уныло. Игнорироавть этот факт - как-то странно: возможность отката к предыдущим состояниям и хранения нескольких верисй файла + неразрушающая запись как бы являются весьма интересной и полезной фичой.
интересно почему ZFS проверяли на freebsd ?
для нее native OS - таки солярис, тестеры не осилили солярку?
или попытка подтасовать результаты что бы показать что linux где-то может выигрывать ?PS. а баг с malloc и NCPU > 8 уже в glibc починили? и glibc уже больше позорно не сливает freebsd в mysql тестах ?
> тестеры не осилили солярку?Phoronix же.
>> тестеры не осилили солярку?
> Phoronix жеНу почему же не осилили... У них даже есть тесты OpenSolaris на EeePC каком-то или чем-то подобном.
Тут дело в не в линуксе, фрибсд или солярке, а в методике тестирования и инструментах для тестирования. Есть их тестового набора некоторые особенности, делающие его малопригодным для тестирования файловых систем.
filebench бы для тестирования именно файловых систем подошел бы гораздо лучше.
>интересно почему ZFS проверяли на freebsd ?Крутые ребята, юзающие zfs на солярке, фороникс не читают.
ну вот, бздишеки запели - настройки не те, ось не та, код нужно по свежее,...
все что угодно, лишь бы не признавать тот факт, что такой отрыв никакими настройками не исправишь.кстати, свежий код еще не признак улучшений скорости. вот в 35 ядре регрессии.
и еще, аргумент "ось не та" эпичен. вам же линусоиды сразу говорили, что ваша ось "не та". :D
>ну вот, бздишеки запели - настройки не те, ось не та, код
>нужно по свежее,...
>все что угодно, лишь бы не признавать тот факт, что такой отрыв
>никакими настройками не исправишь.
>
>кстати, свежий код еще не признак улучшений скорости. вот в 35 ядре
>регрессии.
>и еще, аргумент "ось не та" эпичен. вам же линусоиды сразу говорили,
>что ваша ось "не та". :Dа что там с тредом в lkml о том что btrfs позволяет записать меньше половины диска?
уже поправили?
кстати btrfs уже научилось проверке своих структур? или там хотя бы ENOSPC возвращать ?:)
если взять сырцы из жита - то таки уже да.
или ты всё надеешься, что когда бтр выйдет в продакшн, то zfs вдруг отыграется? :D
>если взять сырцы из жита - то таки уже да.
>или ты всё надеешься, что когда бтр выйдет в продакшн, то zfs
>вдруг отыграется? :Dзачем ему отыгрываться? Интересует производетельность не одного кубика - FS, а системы в целом.
А на последних тестах MySQL на линухе сливает MySQL на фре.
И это факт :)Другими словами может быть очень быстрая FS, но но дерьмовая суммарная производительность.
Так что можешь радоваться финтифлюшкам у FS, но на суммарную производительность это не повлияет :)Продолжайте дальше пускать слюни на свою BtrFS - и надеяться что оракл ее не закроет :)
Когда обезьянки ее вытестируют..
мужик, а может тебе новость про мускуль дождаться, а? не?
ну я так и думал :Dзы:
>Продолжайте дальше пускать слюни на свою BtrFS - и надеяться что оракл ее не закроет :)ну и с кем я это обсуждаю....
ваш уровень образования был виден чуть выше, теперь видно и воспитание.
ты наверное не поверишь, но все эти тесты, которые порвали zfs, как тузик грелку, вполне себе используют глибси.
может это она виновата? :D
Слив засчитан.
где в этих тестах много ? если нет - сливай дальше ;-)
а эти тестеры такие смешные.. зато как у линуксоидов самооценку поднимают ;-)если не осили google то дарю ссылку
эти тесты на лине. а там у глибси альтернативы банально нет. в частности для убунты:
$ aptitude search libc|egrep -i "GNU C Library"
i libc-bin - Embedded GNU C Library: Binaries
i libc-dev-bin - Embedded GNU C Library: Development binari
i libc6 - Embedded GNU C Library: Shared libraries
i A libc6-dbg - Embedded GNU C Library: detached debugging
i libc6-dev - Embedded GNU C Library: Development Librar
и даже если тесты - это скрипты на баш - $ ldd /bin/bash
linux-vdso.so.1 => (0x00007fffa4f92000)
libncurses.so.5 => /lib/libncurses.so.5 (0x00007f7ab200d000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f7ab1e09000)
libc.so.6 => /lib/libc.so.6 (0x00007f7ab1a85000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7ab2281000)
поэтому можешь повышать свою самооценку (видимо больше нечего) на ливжорнале сам.
ещё раз, для одарённых - "бажный" глибси в лине (да ещё, какой ужОс, в бубунте!) таки не помешал "безбажному" бзд опустить zfs ниже плинтуса.
>ещё раз, для одарённых - "бажный" глибси в лине (да ещё, какой
>ужОс, в бубунте!) таки не помешал "безбажному" бзд опустить zfs ниже
>плинтуса.Опустить в синтетическом тесте? да производительность ниже,
а суммарная производительность MySQL ноды в линухе ниже, не смотря на супер-пупер FS.
Можно запросто написать тест который угробит производительность BtrFS (вспоминаем тред в lkml с бывшим разработчиком рейсера).Так что идите дальше радуетесь, а когда догоните фрю на тестах связаных с БД - поговорим :)
>Опустить в синтетическом тесте?ну так опусти.
ждёмс.
>эти тесты на лине. а там у глибси альтернативы банально нет. в
>частности для убунты:а что же такой продвинутый линух не может пофиксить такую позорную регрессию ?:)
>а что же такой продвинутый линух не может пофиксить такую позорную регрессию1. Регрессии фиксят разработчики, а не ядро ОС.
2. Они их фиксят, если они там действительно есть, и у них есть время и желание этим заниматься.
3. Да, проблема с масштабируемостью то ли mysql, то ли glibc красноречиво рассказывает нам о классовом превосходстве zfs, solaris, cddl и sun^Woracle над всеми, кто не. Да-да, однозначно!
да и с такой "позорной регрессией" такая "не позорная фря с zfs" делается в несколько раз.
пускайте слюни на синтетический тест :)
Только это никак не улучшает работу linux под mysq ;-)
ок. отвечу в том же ключе (может ему так понятнее, х/з) -
пускай слюни по своему мускулю под бзд, это никах не улучшит работу zfs в ней же.
зачем пускать слюни?
целиком система работает отлично :)
А то что некоторые ее части работают хуже - ну и лана, это допилят и будет еще лучше.
А вот кичится быстрой работой одной из подсистем - когда целиком система работает хреново - это да это 5 с + :)Хотя видимо у линуксоидов принято кичиться чем-то отдельным хорошо работающим и не замечать что в сумме получается дерьмо :)
Какое тонкое издевательство над ZFS/FreeBSD. :)Phoronix, видимо, не умеет читать README, где фореграундом по бэкграунду написано про vm.kmem_size... ;)
>Phoronix, видимо, не умеет читать README, где фореграундом по бэкграунду написано про
>vm.kmem_size... ;)Phoronix сравнивают в дефолтовой свежеустановленной конфигурации, что IMHO на 100% верно, так как именно такая конфигурации используется подавляющим большинством пользователей. Заявляя, что перед тестами нужно тюнить специфичные настройки можно в конце-концов придти к советам переписать перед тестами проблемный код и исправить самостоятельно все баги.
Это было бы справедливо, если бы инсталятор FreeBSD 8.1 позволял ее ставить на ZFS в процессе обычной установки, без спецподготовки и сложных танцев. Пока этого нет, и ZFS используют энтузиасты, а толковых описаний, как ее тюнить на FreeBSD 8.1, толком и нет - уверен, что каждый ее установивший задумывается о тюнинге под задачи.Тогда уже сравнивали бы UFS, раз разговор про "из коробки" (точнее, сделанное стандартным для ОС инсталятором) завели. А ZFS натюнили бы и сравнивали с другими вручную созданными на носителе(-ях) и тоже натюниными со знанием дела ФС.
Хоть бы обратил внимание, что тест проводился на PC-BSD 8.1, где ZFS как раз из коробки.
Может быть и из коробки, но по сравнению с текущим билдом опенсолярис очень древняя.
бсд вполне себе ось.
если вас утешит, то сравнивались не фс в вакууме, а фс в составе той или иной оси.зы:
конечно хотелось бы результаты посмотреть и с опенсоляркой.
но это не изменило бы результаты в бсд.
Я ниже откоментил.
Заодно надо было брать не 8.1, а, как и случае с Убунтой, код посвежее :)Умеют они теплое с мягким сравнивать, желательно на машине помогучее, чтобы разница свелась к погрешности изменений ;)
при тестировании фс надо брать не "посвежее", а постабильнее.
в случае с бтр выбор понятен - в последнем ядре (а его Линус таки объявил релизом) данная эксперементальная фс ближе к ее релизу, т.е. результаты приближены к будущему продуктивному варианту. видимо именно такой примерно скорости и стоит от нее ждать.
зы:
кстати, результаты бтр не могут не радовать. в общем в однодисковом варианте такая стабильность такой сложной фс (отставание от экст4 в пределах погрешности) - это хороший результат.
>при тестировании фс надо брать не "посвежее", а постабильнее.
>в случае с бтр выбор понятен - в последнем ядре (а его
>Линус таки объявил релизом) данная эксперементальная фс ближе к ее релизу,
>т.е. результаты приближены к будущему продуктивному варианту. видимо именно такой примерно
>скорости и стоит от нее ждать.
>зы:вот в BSD тоже надо было брать то что ближе к релизу :)
а релиз сейчас то что в CURRENT :)
Почему тестировщики заведомо взяли не сравнимые вещи надо их спросить ;-)
это просто всемирный заговор против бзд вообще и вас с zfs в частности.
это же очевидно.зы:
для одарённых в новости есть ещё один абзац.
в частности на люсид (10.04, ядро vmlinuz-2.6.32-24-generic) бтр показывает лучшие результаты. считайте что zfs ещё пожалели.
>это просто всемирный заговор против бзд вообще и вас с zfs в
>частности.
>это же очевидно.
>
>зы:
>для одарённых в новости есть ещё один абзац.
>в частности на люсид (10.04, ядро vmlinuz-2.6.32-24-generic) бтр показывает лучшие результаты. считайте
>что zfs ещё пожалели.Это не всемирный заговор :)
Это лиш показывает степерь объективности данной конторы :) и данного набора тестов ;-)
Пока что он нефига не объективный :)
>Phoronix, видимо, не умеет читать README, где фореграундом по бэкграунду написано про vm.kmem_size... ;)Сравнительное тестирование производительности имеет смысл _только_ в дефолтной конфигурации, иначе оно превратится в соревнование тюнингеров.
С точки зрения писькометрии тюнингеров такое соревнование, может быть, и показательно, однако характеристики софта в этом случае отходят на второй план. Недотюнил какую-то мелочь - и вместро быстрой ФС получаешь тормозилово.
Нет, дефолт - это эталонный уровень.
> Нет, дефолт - это эталонный уровень.(Интеллигентно откашлявшись)
У FreeBSD/ZFS НЕТ эталонного уровня. Инсталляция FreeBSD на ZFS возможна _только_ руками.
Использование ZFS как отдельного хранилища требует, в любом случае, настройки: хотя бы для того, чтобы сказать "kldload zfs". А раз так, то настройку надо производить так, как требует руководство по настройке.
>> Нет, дефолт - это эталонный уровень.
>
>(Интеллигентно откашлявшись)
>
>У FreeBSD/ZFS НЕТ эталонного уровня. Инсталляция FreeBSD на ZFS возможна _только_ руками.
>А как насчёт новость прочитать, там где про PC-BSD?
>
>Использование ZFS как отдельного хранилища требует, в любом случае, настройки: хотя бы
>для того, чтобы сказать "kldload zfs". А раз так, то настройку
>надо производить так, как требует руководство по настройке.
> А как насчёт новость прочитать, там где про PC-BSD?Я внимательно читал новость.
ZFS в PC-BSD _не_ из коробки -- она из коробки в _инсталляторе_ PC-BSD. Если бы она там была _действительно_ из коробки, вот этого вот:
http://trac.pcbsd.org/changeset/2962
не было бы. Повторюсь ещё раз: раз уж вы сказали "kldload zfs", доделайте все остальные шаги, которые описаны в руководстве по использованию ZFS во FreeBSD. :)
забавная отмазка.
$ lsmod|grep btr
btrfs 480609 0
zlib_deflate 21797 1 btrfs
libcrc32c 1284 1 btrfs
зы:
в_инсталляторе - это и есть из_каропки.
>вот:
>http://trac.pcbsd.org/changeset/2962
>не было бы.Да, комент там и правда смешной - Updated the PC-BSD install script to detect if the user is below 1GB of memory when trying to use ZFS, and stop them.
Типа, если у вас меньше гига памяти то даже и не трепыхайтесь? А почему авторы btrfs ничего такого не требуют? :)
>>вот:
>>http://trac.pcbsd.org/changeset/2962
>>не было бы.
>
>Да, комент там и правда смешной - Updated the PC-BSD install script
>to detect if the user is below 1GB of memory when
>trying to use ZFS, and stop them.
>
>Типа, если у вас меньше гига памяти то даже и не трепыхайтесь?
>А почему авторы btrfs ничего такого не требуют? :)Потому что разные требования у разных FS - вы же не требуете что бы RHEL запускался на вашем любимом ARM ?
PS. а BtrFS уже позволяет больше половины винта записывать? а то lkml говорит что если писать мелкие файлы то о производительности и свободном месте можно забыть.
Не подскажете когда это исправят ?
>Потому что разные требования у разных FS - вы же не требуете что бы RHEL запускался на вашем любимом ARM ?с чего бы вдруг? альтлинух вон и то на арм дистр делать стали. отстал ты от жизни.
на арме я и бтр жду. нокия вон обещала в миго. zfs же похоже ждать не приходится. эппл видимо не зря отказалась.
"не_делают_для_арм" и "невозможно_в_приципе" - разные вещи.
>Потому что разные требования у разных FS - вы же не требуете
>что бы RHEL запускался на вашем любимом ARM ?А интель сватает бтрфс как дефолтную ФС в meego :).Откуда напрашивается вывод что ФС совсем не обазательно требовать с ножом к горлу гигазы памяти.Более того - похоже на то что куча оперативы нужна для вытягивания далеко неидеального дизайна ZFS из понятно какого места.
>PS. а BtrFS уже позволяет больше половины винта записывать?
Вы не поверите, но если писать 20-байтовые файлы - у вас вообще поюзается менее 1/10 винча.Даже на традиционных блочных ФС с классическим выделением блоками.Чисто за счет биения на блоки. И даже если есть tail packing (правда тогда хана производительности), метаданные выжрут существенный объем, вероятно сильно больше чем объем данных.
>а то lkml говорит что если писать мелкие файлы то о производительности и свободном
>месте можно забыть.А если взять файлы нулевого размера - КПД любой ФС будет ноль. Потому что бесконечное число файлов на диск не влезет: метаданные что-то занимают и займут весь том (если раньше не вылезут лимиты структур ФС). В итоге суммарно на томе 0 байтов в файлах а места на диске нет. Не знаете когда исправят такое безобразие? :)
> Не подскажете когда это исправят ?
Для клинического случая? А никогда. Иначе станет возможен бесконечный архиватор, сохраняющий данные из файла в именах файлов 0-й длины (один такой кто-то даже написал). Обратной процедурой ессно можно вернуть данные в файл :)
>>Потому что разные требования у разных FS - вы же не требуете
>>что бы RHEL запускался на вашем любимом ARM ?
>
>А интель сватает бтрфс как дефолтную ФС в meego :).Откуда напрашивается вывод
>что ФС совсем не обазательно требовать с ножом к горлу гигазы
>памяти.Более того - похоже на то что куча оперативы нужна для
>вытягивания далеко неидеального дизайна ZFS из понятно какого места.Я спрашивал о RHEL, а не о meggo. Если до вас не дошло сформулирую вопрос иначе - почему системы которые запускаются на разном железе - требуют разного тюнинга ?
Или вы с пеной у рта будете доказывать что ядро meggo такое же точно как RHEL ?>
>>PS. а BtrFS уже позволяет больше половины винта записывать?
>
>Вы не поверите, но если писать 20-байтовые файлы - у вас вообще
>поюзается менее 1/10 винча.Даже на традиционных блочных ФС с классическим выделением
>блоками.Чисто за счет биения на блоки. И даже если есть tail
>packing (правда тогда хана производительности), метаданные выжрут существенный объем, вероятно сильно
>больше чем объем данных.Не больше - рейсерфс этому пример и с производтельностью там нормально.
Не стоит теоретизировать там где не разбираешся.
>[оверквотинг удален]
>занимают и займут весь том (если раньше не вылезут лимиты структур
>ФС). В итоге суммарно на томе 0 байтов в файлах а
>места на диске нет. Не знаете когда исправят такое безобразие? :)
>
>
>> Не подскажете когда это исправят ?
>
>Для клинического случая? А никогда. Иначе станет возможен бесконечный архиватор, сохраняющий данные
>из файла в именах файлов 0-й длины (один такой кто-то даже
>написал). Обратной процедурой ессно можно вернуть данные в файл :)Там вроде как был далеко не клинический случай. Так и запишем в BtrFS дизаин дерьмовый, раз такую очевидную проблему не исправляют.
Фороникс почитать, так вообще FAT везде ставить надо, по их тестам он будет быстрее в силу своей деревянности.
Ну, таки, допустим, будет. Но тогда важны другие особенности фс. А это уже не рассматривается в тестах производительности phoronix. :D
>в силу своей деревянности.О! А где они деревянность %) тестировали??? Ссылку, сестра+++
О, вы таки меня убедили, btrfs и zfs не нужны, потому что фороникс и вы таки сказали что и более деревянные ФС в меру надёжны и данные на них почти не падают, а уж если и файлы более 2Гю хранить не надо и комп у вас конфига как мой Asus WL500 (что по частоте, что по ОЗУ), то однозначно FAT и ничего кроме. Ходят конечно слухи что такой комп прекрасно переживёт EXT*/UFS, но зачем рыпаться то? У соседа Васи Пупкина всё равно w98
А кроме хомячковых форониксовских селеронов ещё и серверов не существует, во как.
в каком месте он тебя убедил?кстати, данный тест был на и7 с 4гб и оси были 64-битные.
те все требования для zfs выполнены.
а результат - бтр работает также, как и экст4, а zfs сливает - наверное логично приводит таких аналитегов к фату.
>вас конфига как мой Asus WL500 (что по частоте, что по
>ОЗУ), то однозначно FAT и ничего кроме.А что делать с тем что он файлы >4Gb не поддерживает?
>по их тестам он будет быстрее в силу своей деревянности.Достаточно открыть папку с несколькими тыщами файлов и оценить всю деревянность на своей заднице :)
Кто-нибудь знает, почему logfs.org лежит?
ФС на серваке посыпалась :)
>ФС на серваке посыпалась :)Вероятно. ) Хотел на рут поставить на свое "ссд", а оно в сегфаульт падает. :D Пока придется nilfs юзать с его невменяемым сборщиком мусора. (
А оно - это кто?
>А оно - это кто?transcend cf 133x 8gb через переходник на thinkpad 570e
>А оно - это кто?Ты заставил меня прочитать свой собственный пост. Оно - это ядреный модуль logfs. Про ошибку сегментации я чего-то попутал, был не в теле. :D Тут явно другое.
Aug 9 17:39:13 serv kernel: [ 2692.043761] ------------[ cut here ]------------
Aug 9 17:39:13 serv kernel: [ 2692.043810] kernel BUG at /build/buildd-linux-2.6_2.6.35~rc6
-1~experimental.1-i386-4Qihez/linux-2.6-2.6.35~rc6/debian/build/source_i386_none/fs/logfs/se
gment.c:47!
Aug 9 17:39:13 serv kernel: [ 2692.043880] invalid opcode: 0000 [#1] SMP...
могу всю портянку с трейсом скинуть, если интересно.
Интересно, за сколько убьёт SSD диск файловая система EXT4 со всем своим мегажурналированием и постоянной записью в туеву хучу мест?
Именно по этой причине на свой EEE PC с SSD-диском пришлось поставить EXT2 вместе EXT3...
То, что в вашем EEE PC, отстает от современных SSD ровно на 2 поколения :) . Проблем там нет.
>То, что в вашем EEE PC, отстает от современных SSD ровно на
>2 поколения :) . Проблем там нет.+1
И я бы лучше ext4 тогда поставил. ;) На моем "poor man's ssd" оно быстрее (было) чем ext3. Буферизация, чего ж ты хош. Сейчас на nilfs, ибо нежурнальные фс встают раком на random write. :E
Ну почитайте же цифры, заявленные производителями SSD и перестаньте верить древним мифам (да, первые эксперименты с SSD действительно было довольно погаными, но это совсем не тот уровень, который есть сейчас)http://www.storagesearch.com/ssdmyths-endurance.html
http://robert.penz.name/137/no-swap-partition-journaling-fil.../Ваш SSD проживет 50 лет, если писать на него 50 мегабайт каждую секунду и лет 500 при более типичной картине записи. Intel дает гарантию 5 лет вроде?
Пишете вы в один сектор или разные, неважно, внутри SSD умный чип и журнал, постоянно меняющий отображение физических ячеек чипа и логического сектора диска (для ОС "физического"). Вот тут хорошее объяснение http://lwn.net/Articles/353411/
>Интересно, за сколько убьётwear leveling давно есть на всем, что можно купить в магазине (флеш-карточки, брелочки, пирожки и т.п.). на еее - хз чего там.
Интересно когда люди научатся man'ы читать где написано что ext4 прекрасно и без журнала может работать.
> написано что ext4 прекрасно и без журнала может работать.Понятия о прекрасном у всех разные :)
Ну раз в 36 пофиксят, то нестрашно. А вообще, просветите, формат уже "зафиксирован"? То есть, если я сейчас на бтрфс перейду, то могу быть уверен, что не придется переформатировать?
бтр имеет такое устройство, которое позволяет легко конвертировать ext[3-4] в btrfs и обратно.
https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3
http://xgu.ru/wiki/btrfs#.D0.9F.D1.80.D0.B5.D0.B2.D1.80.D0.B...
Вообще, мысль - так уж наверняка будет. Спасибо.
у них метаданные не пересекаются. так что процесс в общем безобидный.
главное ext2_saved не удаляй.
конечно место будет занимать, но и конвертнуть обратно можно будет
>позволяет легко конвертировать
>и обратно."Можно вернуться на файловую систему ext3 и потерять сделанные изменения:"
Не позволяет, не совсем легко, совсем не обратно, но да....
э-э-э, да. это я как то упустил.
снапшот ext2 монтируется только в ro (может пока). соответственно изменения на_лету не обновишь. ну хоть можно сравнить содержимое и нужное забэкапить.
ну, наверное ещё вот это можно порекомендовать - https://btrfs.wiki.kernel.org/index.php/Rescue_me
думаю в будущем даже если формат будет менятся, то и будут соответсвующие утилиты для изменений.
Странно, почему jfs и xfs игнорируются?Использую ноутбук с SSD более года. Использую активно, почти полностью забит. От ext4 отказался, так как она себе на журнал отняла чуть ли не 2 гигабайта от размера диска. Полгода сидел на XFS, но скорость копирования файлов иногда была необоснованно маленькой. Да и системный раздел в 6 гигабайт почему-то стал распухать, а XFS не поддерживает уменьшения размера раздела, так что от /home оторвать кусок бы не удалось.
Теперь сижу на jfs. Доволен и скоростью работы (как при загрузке, так и при работе) и отсутствием повреждения данных (с чем столкнулся при использовании ext4) и отсутствием нагрузки на процессор.
PS SSD Samsung на 128 гигабайт.
вообще то никогда не рассматривал ни xfs, ни jfs для использования на ssd.
использую xfs на 2-х терах файлопомойки (программный 5 рэйд), да и то, сам рут на ext3 (внутренние винты, аппаратное зеркало).
доволен как слон.
Тред немного уже затухает, но главный вопрос икс: а зочем zfs на "домашнем" компе??? Для файлопомойки - гут, а работать-то на нём зачем?....)
>Тред немного уже затухает, но главный вопрос икс: а зочем zfs на
>"домашнем" компе??? Для файлопомойки - гут, а работать-то на нём зачем?....)
>Скорость? Кто-то любит со снимков backup делать. Чего там еще интересного то есть? =\ Ну да, и от cow еще ни кто не умирал. ) А так, и на ext4 можно вполне.
Фрониксы без приколов не могут, теперь они тестируют серверные ФС на ноутбуке с кастрированным процессором.-----
Кстати, давеча обнаружил в BTRFS 4 мямлика.
>Кстати, давеча обнаружил в BTRFS 4 мямлика.Ху из "мямлик"?
>>Кстати, давеча обнаружил в BTRFS 4 мямлика.
>
>Ху из "мямлик"?Как вы не знаете мямлика?! - це это ж Memleak :)
>Как вы не знаете мямлика?! - це это ж Memleak :)Благодарствую!
>>Как вы не знаете мямлика?! - це это ж Memleak :)
>
>Благодарствую!Включи CONFIG_DEBUG_KMEMLEAK увидишь. Выскакивает только при монтировании.