Исходное сообщение
"Релиз Linux-ядра 2.6.34" Отправлено mnu, 18-Май-10 16:25
> Copy-on-write зарулит нафиг все эти потуги. Хорошие вещи должны быть простыми и не костыльныим. Хм. Единственная production-ready (tm) FS на *BSD, построенная на технологии CoW - это ZFS, жрущая кучу RAM и дико тормозная при 95%+ занятости места на zpool'ах. Из не-production-ready есть HAMMER, по возможностям в некоторых местах превосходящий Btrfs, а в некоторых (сжатие, например) - всё ещё ей уступающий. Но HAMMER пока ещё не настолько стабилен, как UFS. Памяти жрёт меньше, чем ZFS, это да. Отжирает только в момент reblocking'а. Ни HAMMER, ни ZFS простыми не назовёшь. Не назовешь простой так же и XFS с reiserfs (которые в FreeBSD read-only). При использовании UFS + SUJ при более чем приемлемом быстордействии Вы сохраните оперативную память. При использовании async UFS + geom_journal Вы жертвуете ~1Gb под журнал и имеете производительность, соизмеримую с любой развитой journalled FS (с теми же ограничениями). В обоих случаях Вы не рискуете целостностью Ваших данных, Вам практически наплевать на фрагментацию (в отличии от ZFS) и RAM'ы кушается не много. А UFS2 нужен в основном для ОЧЕНЬ больших (>226Tb) FS да для всяких хитрых ACL... Ну, ускоряет немного благодаря delayed inode allocation, да, но ето не особо важно. Команда DragonFLyBSD вообще наплевала на UFS2, резонно решив, что лучше потратить время на стабилизацию HAMMER'а.