В состав Linux ядра 2.6.29 будут включены файловые системы Btrfs и Squashfs

>>> как и Ext4 — долгожданная замена UFS2

>>Ы? Может, ты хотел сказать "аналог"?

>Не, не аналог, а именно замена.

Менять можно то, что использовалось. В Линуксе ufs2 не использовалась никогда, а в FreeBSD ext4 пока нет.

Мне кажется, или нормальных opensource-проектов раз два и обчелся? По сути только ядро вменяемо написано и всякие проги, которые разрабатывают с позабытых времен.

>А злые дебиановцы к и без того распухшему ядру ещё добавили аж пять дивиди дисков всякого ненужного гавна! НЕТ ПУТИ! mironov_ivan ** (*) (11.01.2009 1:22:38)

Что то бздануло, или мне показалось?.

Дня не проходит чтобы, какая то гадость не пробздела по беспонту.

о! опередили. А то я уж решил придется объяснять пионерам.
Живо представил себе обсуждения lvm sucks

Чего-то я не врубаюсь.... С какого бодуна вы сравниваете снапшоты ФС(ZFS, BTRFS) со снапшотами блочных устройств(LVM) ?

Вы что, обкурились ? (с) :)

Особенно понравилась шутка iZEN про UFS2

аффтар жжот, пиши исче (c)

Дядя, чем оно (UFS2) лучше ext3, ReiserFS, XFS, JFS ?

По сравнению с последними 3 оно вообще каменный век, с ext3, НЕТ даже с ext2 у них возможно паритет, только по скорости UFS2 в полной Опе

Надеюсь что Tux3 (http://tux3.org/) тоже включат когда будет доделан kernel port и окончательно заморожена структура ФС. Судя по нынешним темпам разработки это будет достаточно скоро.

>Дядя, чем оно (UFS2) лучше ext3, ReiserFS, XFS, JFS ?

Чем Ext3 — UFS2 включена в ядро FreeBSD где-то в 2002 году. Эта ФС распределяет пространство не на уровне блоков, а на уровне фрагментов блоков ("экстентов" как в Ext4, 64-битную адресацию), что сильно уменьшает фрагментированность файлов при интенсивных операциях перезаписи одного и того же участка диска, дефрагментация ненужна. UFS2 поддерживает создание моментальных снэпшотов ФС. UFS2 обеспечивает транзакции метаданных с помощью механизма Soft Updates. Всё это даёт возможность fsck работать в фоновом режиме и восстанавливать файловую систему после краха на работающей машине (сохранность файлов не гарантирована — гарантирована только непротиворечивость файловой системы).

Чем RaiserFS, XFS, JFS — UFS2 универсальна, и не может соперничать со специализированными ФС по всем характеристикам.

>По сравнению с последними 3 оно вообще каменный век, с ext3, НЕТ даже с ext2 у них возможно паритет, только по скорости UFS2 в полной Опе

"Каменный век" — это Ext2 и прикручивание журналирование к ней в 2001 году (Ext3).
Скорость UFS2 зависит от объёма и быстродействия оперативной памяти и скоростных характеристик носителя, так как частенько используется Soft Updates. Тесты скорости на относительно современных носителях проведены: http://citkit.ru/articles/1099/2.html

>К тому же Ext4 не умеет "Soft Updates"

Потому что они там не нужны.

>Скорость UFS2 зависит от объёма и быстродействия оперативной памяти и скоростных характеристик носителя, так как частенько используется Soft Updates.

Чем оно лучше журнала?

Боже, ссылка на Федорчука. Ню-ню.

Я процитирую:

>>Последнее особенно ощутимо для операции валового копирования с раздела на раздел. Напомню, что раздел-источник располагался на другом диске и нёс на себе файловую систему ZFS. Сочетание этих факторов, видимо, и определило столь значительный отрыв от аналогичной операции для файловых систем Linux, где валовое копирование выполнялось между разделами, лежащими на одном диске, а раздел-источник нёс на себе файловую систему ext3 (ordered): при копировании массива данных на файловые системы Linux, лежащие на программном RAID'е, преимущество UFS (и ZFS) оказывается не столь явным.

Можно поинтересоваться, что же он с чем сравнивал и как?

Особенно порадовала более медленная ext2 по сравнению с ext3...

Кстати, было бы здорово для сравнения врубить sync.

> Что общее у Ext4 с UFS2 и нет в других "классических" FS:
> 1) универсальность;
ext3, reiserfs, xfs, jfs - универсальные. В том смысле, что каждую можно использовать под любую задачу и это не будет выглядеть абсурдно.

2) моментальные снапшоты;
XFS. У меня в качестве теста и reiserfs нормально замораживалась при создании lvm snapshot...

3) распределение пространства экстентами, а не целыми блоками.
целыми->отдельными или я не понял мысль? XFS, вроде, так же делает, но тут я не уверен.

> Дня не проходит чтобы, какая то гадость не пробздела по беспонту.

слы паря, семки есть ?

>Можно поинтересоваться, что же он с чем сравнивал и как?

Спросите у него.

"Мопед не мой. Я только разместил объяву" (с)

Всё-таки каждая ФС, кроме Ext2/3, представляет собой оптимизацию в плане типичных операций над определёнными файлами (размер файлов немаловажен) и определённый способ распределения дискового пространства.

Моментальные снапшоты с lvm не считаются.

> Тесты скорости на относительно современных носителях
> проведены: http://citkit.ru/articles/1099/2.html

>> Напомню, что раздел-источник располагался на другом диске
>> и нёс на себе файловую систему ZFS. Сочетание этих факторов,
>> видимо, и определило столь значительный отрыв от аналогичной
>> операции для файловых систем Linux, где валовое копирование
>> выполнялось между разделами, лежащими на одном диске

О боже мой... А это ничего, что при операция копирования в
пределах одного диска по определению почти в два раза медленне,
чем операция копирования между разными дисками?

Первый тест - собственно создание файла:

[root@viking mnt]# dd if=/dev/zero of=/mnt/test1/demo.bin bs=4096 count=102400
102400+0 records in
102400+0 records out
419430400 bytes (419 MB) copied, 8,29767 s, 50,5 MB/s

Обратите внимание на скорость - она близка к скорости
записи данных на носитель. Теперь сбросим кэш

[root@viking mnt]# umount /mnt/test1
[root@viking mnt]# mount -t ext3 /dev/serenity/test1 test1

и протестируем время параллельного чтения с одновременной
записью в пределах одного винта:

[root@viking mnt]# dd if=/mnt/test1/demo.bin of=/mnt/test2/demo.bin bs=4096 count=102400
102400+0 records in
102400+0 records out
419430400 bytes (419 MB) copied, 14,3889 s, 29,1 MB/s

Опа! Скорость падает почти в два раза. Какая самая медленная
операция низкоуровневого ввода-вывода? Правильно, самая
медленная это seek. А их тут много.

К сожалению, второго винта у меня в рабочую станцию не воткнуто,
поэтому я не могу показать вам, что скорость копирования когда
источник и назначение расположены на разных устройствах. Но можете
поверить - она чуть ниже (примерно на 5-7%) скорости самого
этих двух медленного из устройств - то есть если бы у меня было
два одинаковых винта, скорость копирования между ними была бы порядка
50МБ в секунду. А это означает, что в таблице федорчуковских "тестов"
в тестах копирования ISO-шника и AVI-шника линуксовое время можно
смело умножать на 0.6 (поскольку 30/50 = 0.6). С учетом поправки,
можно сделать вывод, что Ext3 на тестах копирования ISO и AVI
процентов на 30-40 быстрее чем ZFS, а UFS2 вообще не жилец.

А теперь еще один забавный тест, чтобы определить поправочный
коэффициент для результатов Федорчуковского "теста" с мелкими
файлами и понять что к чему:

Берем исходники линуксового ядра и загружаем их в кэш VFS:

[root@viking test2]# dd if=/tmp/linux.tar of=/dev/null
365900+0 records in
365900+0 records out
187340800 bytes (187 MB) copied, 0,379086 s, 494 MB/s

А теперь смотрим время, за которое это дерево будет создано:

[root@viking test2]# time tar -xf /tmp/linux.tar
real 0m2.732s
user 0m0.089s
sys 0m1.052s

Неплохо, очень неплохо - примерно 3 секунды. VFS линукса ОЧЕНЬ хороша.
Посмотрим, за сколько времени эти же данны прочитаются?

[root@viking mnt]# umount test2
[root@viking mnt]# mount -t ext3 /dev/serenity/test2 test2
[root@viking mnt]# cd test2
[root@viking test2]# time tar -cf /dev/null linux-2.6.0
real 0m3.967s
user 0m0.076s
sys 0m0.192s

Всего за 4 секунды. Охренеть. Причем это подъем с диска(!)
ибо весь кэш был сброшен при перемонтировании. С учетом того,
что говорилось ранее чтении/записи на разные устройства,
суммарное время операции копирования будет примерно равно
(T(чтения)+T(записи))*Поправка.

Время операций I/O будет (4+3) то есть 7 секунд.
Примем поправку в 1.2 - то есть увеличим время еще на 20%,
и получим примерно 8.5 секунд на весь цикл копирования между
разными устройствами. А что у нас с копированием в пределах
одного устройства - насколько seek ухудшит показатель?

[root@viking mnt]# umount test1
[root@viking mnt]# umount test2
[root@viking mnt]# mount -t ext3 /dev/serenity/test2 test2
[root@viking mnt]# mount -t ext3 /dev/serenity/test1 test1
[root@viking mnt]# cd test2
[root@viking test2]# time cp -R linux-2.6.0 /mnt/test1
real 0m24.073s
user 0m0.086s
sys 0m1.858s

Угу, понятно - 24 секунды. Дорогой seek, ОЧЕНЬ дорогой.
Время копирования в пределах одного устройства в два с лишним
раза больше чем в между разными устройствами. Значит, результат
теста с копированием множества мелких файлов у Федорчука
в случае Ext3 надо умножать на 0.35 (8.5/24). И что мы
видим? Ой что мы видим... Время копирования у Ext3 будет
уже не 1:41, а 35 секунд. ZFS может оказаться чуть быстрей - 29
секунд. А может и чуть проиграть - мы ведь накинули 20%, а это
не меньше 6 секунд, а UFS2 по-прежнему в заднице.

>Скорость UFS2 зависит от объёма и быстродействия оперативной памяти и скоростных характеристик носителя, так как частенько используется Soft Updates. Тесты скорости на относительно современных носителях проведены: http://citkit.ru/articles/1099/2.html

Мдяяя... а скорость ext3 зависит можно подумать от положения луны ?

>Чего-то я не врубаюсь.... С какого бодуна вы сравниваете снапшоты >ФС(ZFS, BTRFS) со снапшотами блочных устройств(LVM) ?

>Вы что, обкурились ? (с) :)

Ага!

Вопрос был тупой и откровенно ламерский.
Условия были таковы: есть раздел на 50Gb, занятый в данный момент на 20Gb миллионами мелких файлов в maildir, место постепенно заполняется. Надо было придумать, каким наиболее быстрым образом его бэкапить.
tar при таком количестве файлов - откровенный тормоз.
Совместная коллегия анонимусов сказала ждать btrfs и делать снапшоты ФС, потому что dd пятидесяти гигов с дальнейшим копированием по сети - слишком нерационально.

> Условия были таковы: есть раздел на 50Gb, занятый в данный момент на 20Gb миллионами мелких файлов в maildir, место постепенно заполняется

Все зависит от того, насколько именно постепенно, и какая политик архивирования, как хранятся бэкапы (срок) и тп. Если раздел заполняется на 2GB в день и объем изменений еще 2GB, а бэкапы хранятся 7 дней, то потребное свободное место для однодневного снапшота 6GB. То есть снапшот, затем tar -cvj и вперед по сети, с учетом способности почты сжиматься это будет примерно 3 гигабайта. Копейки, в общем-то.

>Не, не аналог, а именно замена. К тому же Ext4 не умеет "Soft Updates".

iZEN, ты опять показываешь свою беспросветную тупость.

http://mail-index.netbsd.org/netbsd-announce/2008/12/14/msg000051.html

From NetBSD 6.0 onwards, soft
dependencies will no longer be shipped as part of the system and logging
will be the preferred method of maintaining file system integrity with FFS
file systems.

Т.е. Wasabi Systems закоммитили журналирование, в 5.0 это отладят, в 6.0
выкинут нахрен soft updates.

Так что SU - это костыль для тех, кто не асилил журналирование.

>Всё это даёт возможность fsck работать в фоновом режиме и восстанавливать файловую систему после краха на работающей машине

класс. а теперь в процессе выполнения background fsck вырубаем питание.
И тут(сюрприз!!!) будет полный fsck, а загрузка машины будет остановлена до момента его завершения(что на современных винтах выливается в 20-30минут).

>Спросите у него.
>"Мопед не мой. Я только разместил объяву" (с)

зачем ссылаться на сомнительные данные?

>Моментальные снапшоты с lvm не считаются.

почему?

> GRUB/GRUB2 уже умеет загружать ядро с Btrfs?

lilo умеет. Ему вообще пофиг на фс!

>>Моментальные снапшоты с lvm не считаются.

>почему?

Патамушта марамушта ))

Сделай на своём lvm снапшот xfs и радуйся тому что половина файлов пропала, а другая половина забита нулями.

>Сделай на своём lvm снапшот xfs и радуйся тому что половина файлов пропала, а другая половина забита нулями.

xfs_freeze просто так придумали?

>>Дядя, чем оно (UFS2) лучше ext3, ReiserFS, XFS, JFS ?

>Чем Ext3 — UFS2 включена в ядро FreeBSD где-то в 2002 году. Эта ФС распределяет пространство не на уровне блоков, а на уровне фрагментов блоков ("экстентов" как в Ext4, 64-битную адресацию),

Когда прочтете в википеди, что такое extent, возвращайтесь, и больше подобные глупости не пишите.

http://ru.wikipedia.org/wiki/Экстент

"Экстенты и блоки

Во многих файловых системах, в общем случае файл хранится в виде «заголовка», то есть некой относительно небольшой структуры данных (например, inode и косвенных блоков в ext3 или строки Master File Table в NTFS), который содержит указатели на участки носителя информации, где по кускам хранится содержимое файла. В традиционных файловых системах, это указатели на отдельные блоки (минимальные участки носителя, который можно прочесть или записать за раз). В ряде современных файловых систем используются указатели не на блоки, а на экстенты.

Использование указателей на экстенты имеет ряд преимуществ над схемой с указателями на отдельные блоки. Поскольку все данные в одном экстенте расположены на диске подряд, повышается скорость чтения и записи файла и понижается степень фрагментации дискового пространства. При одинаковом размере и организации структуры данных «заголовка» файла, файловая система с поддержкой экстентов будет иметь больший максимальный размер файлов."

Получается, что экстент == куча блоков, тупо идущих подряд? Или домыслы? Значит я зря поставил знак равенства между фрагментами блоков и экстентами.

>>Всё это даёт возможность fsck работать в фоновом режиме и восстанавливать файловую систему после краха на работающей машине

>класс. а теперь в процессе выполнения background fsck вырубаем питание.
>И тут(сюрприз!!!) будет полный fsck, а загрузка машины будет остановлена до момента его завершения(что на современных винтах выливается в 20-30минут).

Да ты, как я вижу, туп! fsck работает с моментальным снэпшотом некорректно остановленной ФС. Когда работа завершена, fsck транзакцией обновляет основную ФС и делает её непротиворечивой практически моментально.Вырубание питания во время работы fsck может убить только Ext3, XFS и Raiser3.

>xfs_freeze просто так придумали?

Там такая задница… Где-то надо делать xfs_freeze (и если не сделаешь, получишь хлам в снапшоте), где-то (в свежих ядрах) ни в коем случае (иначе lvcreate зависнет).

>во фряхе она менее оттестирована, но ее уже можно гонять в продакшене

типично бздунский подход к продакшену, или ufs древнее некуда или новомодное говно, чтобы хвастаться подключившись putty (тоже бздунский инструмент N1)

>Особенно понравилась шутка iZEN про UFS2

изень поражен тяжелым бздунизмом остатков мозга. ему просто не с чем сравнивать - опыта нет (ну кроме вантуза в злоупотреблении которым он был уже замечен), а тявкнуть очень хочеться - возраст, гормоны, более успешный и удобный линь опять же перед глазами

>Причем это подъем с диска(!) ибо весь кэш был сброшен при перемонтировании.

В линуксе кешируются и данные блочных устройств (pagecache), а при размонтировании FS сбрасываются лишь dentry и inode cache, поэтому для полного сброса кешей нужно поспользоваться командой
echo "3" > /proc/sys/vm/drop_caches
только перед этим нужно сделать sync, т.к. "грязные" буферы через drop_caches не сбрасываются

> В линуксе кешируются и данные блочных устройств (pagecache), а при размонтировании FS сбрасываются лишь dentry и inode cache,

Не говори умных слов, смысла которых не понимаешь :)

>Не говори умных слов, смысла которых не понимаешь :)

может про освобождение dentry и inode я не все знаю, но pagecache при отмонтировании точно не очищается

> pagecache при отмонтировании точно не очищается

А счетчик кэшированных данных в top идет вниз, с чего бы это? ;) Кроме того, посмотри на пример no-dashi, там соль в том, что pagecache после монтирования заполняется заново. Или ты считаешь, что pagecache с отмонтированного диска используется повторно при повторном монтировании? :D

Лажа-то какая =) До этого просто с loop-образами игрался, заигрался! Каюсь, о мой господин - сбрасывается гад! :D Правда мой способ хорош тем, что отмонтировать ничего не нужно =)

>До этого просто с loop-образами игрался, заигрался!

В смысле: у меня после перемонтирования скорость чтения файла с образа FS (который сам хранится ввиде файла) держится на уровне 300Мб/c, что не соответствует физической скорости чтения, которая в этом месте диска составляет порядка 45Мб/c

>держится на уровне 300Мб/c

Вообще-то просто скорость копирования из кеша в /dev/null у меня составляет порядка 700Мб/c, но копирование в моем случае происходит сначала из кеша где лежит файл-образ fs в кеш loop-fs, а потом уже из кеша loop-fs в /dev/null, т.е. где-то в 2 раза медленней, что и наблюдается =)

Экстент - это куча последовательных блоков. Причем их количество может быть различным от экстента к экстенту.

Linux rules! Ура! Ура! Ура! Захотели - сделали.

Теперь по комментариям.

Народ, мне за вас стыдно!

Я зол потому что кто-то не знает что такое снапшоты! WTFT tar??? 20Гб??? Уроды, RTFM - http://ru.wikipedia.org/wiki/Снапшот. В LVM и BTRFS/ZFS это реализовано по разному, на разных уровнях, и измерять эту разницу в размере снапшота как минимум глупо.

Зачем линуксу это "дублирование функциональности" вы спросите?

Затем, что LVM - это костыль, но хороший и рабочий костыль. Имеющий право на жизнь. Он был нужен. Его костыльность заключается в добавлении лишней сущности, в том что реализация структуры и операций с логическими томами на уровне блочного устройства априори менее функциональна чем их реализация на уровне ФС. Собственно этим FreeBSD без ZFS отставала от Соляры, и от Linux'а c его LVM. А теперь Linux отстает от них обоих. BTRFS в ядре выводит его вперед, хотя бы из за GPL. Только жалко что разработчики с ним так торопятся.

Мне стыдно что присутствующие БЗДшники (если они тут конечно есть) не знают ни сильных сторон своей системы, ни ее слабых сторон. RTFM. Соляре - GPL, Linux'у - BTRFS, FreeBSD - жизнь! Рано хороните старушку, господа. Она еще полетает...

SquashFS в ядре это, имхо, роскошь, но раз уж Линус одобрил подобное начинание, давайте кушать пчелу.

Captcha - healets. Ребята, давайте жить дружно! (с)

>Экстент - это куча последовательных блоков. Причем их количество может быть различным от экстента к экстенту.

Да, спасибо, я это уже понял.
UFS2 работает на уровне фрагментов блоков, так что это другое.

> Тесты скорости
о чём говорить с человеком который подкачку выделяет по правилу" размера ОЗУ"!:-)

> Вырубание питания во время работы fsck может убить только Ext3, XFS и
> Raiser3
добавь туда ещё как минимум UFS на Соляре и на фрюхе releases 2-5 без SU!
основание: личный опыт & blogs.sun.com

> SquashFS в ядре это, имхо, роскошь,

это не роскошь
это необходимость
количество поддерживаемых фс на производительности ядра как бы не влияет