Вышла новая версия Btrfs v0.17

http://bugzilla.kernel.org/show_bug.cgi?id=12435 мощно

"Вырубай свет. Они на свет лезут" // О скорости появления новых FS в ядре.

Батька Мортон: "I think it's a feature :)"

Начит так надо :D

"Добавлен режим компрессии данных используя алгоритм zlib."

Вот это радует. Будет на соседнем с Reiser4 разделе жить после сессии =)

баги, заявленные как features - это сильно!

> После включения Btrfs в ядро... Основные изменения:
>
> 1. Изменен формат FS.

О как, йопт!

> Improved block allocation routines (Josef Bacik)

фамилия со славянскими корнями ?

> http://bugzilla.kernel.org/show_bug.cgi?id=12435 мощно

Ну так они об этом сами честно предупреждают!

Currently IO errors and disk full conditions are not handled properly.

http://btrfs.wiki.kernel.org/index.php/Development_timeline

>Изменен формат FS.

чорт, а я уже думал корень на бтр садить...

// все-таки надо будет.

>Btrfs

Ещё не хватает TachankaFS

Ладно. Расскажите зачем создавать FS внутри FS. Я так навскидку не особо понимаю.

> Ладно. Расскажите зачем создавать FS внутри FS.

Родительская и дочерняя абсолютно идентичны (клон), но в родительскую писАть можно, а вот в дочернюю нет. Причем после записи данных в родительскую фс, возможно их мгновенное чтение из дочерней фс. На сколько я понимаю, это просто секьюрити фишка.

Мне вот интересно - ReiserFS4, которая уже почти допилена, только слегка не стабильна уже много лет не могут включить в ядро. А FS, которая ещё даже не определилась с форматом записи на диск - включают запросто. Где логика?

По теме: очень интересно, зачем нужно Seed device.

Подмонтировать ту же фс в другое место в режимо ro никак?

>Мне вот интересно - ReiserFS4, которая уже почти допилена, только слегка не стабильна уже много лет не могут включить в ядро. А FS, которая ещё даже не определилась с форматом записи на диск - включают запросто. Где логика?

Как попасть в ядро быстрее? Так же, как в шоу-бизнесе :)))

А еще расскажите как они сделали writeable snapshots!

> Подмонтировать ту же фс в другое место в режимо ro никак?

Вот описание как оно работает:

#-------------

#First initialize 'seed device'
mkfs.btrfs /dev/vdb
mount /dev/vdb /mnt
btrfs -S subvol /mnt
echo hello > /mnt/subvol/xxx
umount /mnt

#Make block device a "seed device" (read-only)
btrfstune -S 1 /dev/vdb

#Mount the seed device... it will be mounted read-only.
mount /dev/vdb /mnt

#Add the writeable block device
btrfs-vol -a /dev/vdc /mnt

#Now remount the filesystem read-write.
mount -oremount,rw /mnt

#Now all changes to /mnt should go to /dev/vdc.

#--------------

> Где логика?

Она будет помечена как experimental, также это было до версии 2.6.28 с ext4.

Покажи уже мне ReiserFS4 в любом виде в ядре.

Честно сказать, всё равно мало что понял. Разве в таком случае недостаточно будет mount /dev/vdc /mnt ? Или подразумевается, что на vdc идут только измененные данные?

> Мне вот интересно - ReiserFS4, которая уже почти допилена, только слегка не стабильна уже много лет не могут включить в ядро.

Reiser4 никогда не попадет в ядро, так как она сильно абстрагирована от VFS.

> Покажи уже мне ReiserFS4 в любом виде в ядре.

Где я пиcал про Reiser4??? Я написал про ext4! Разницу чувствуешь?

Разницу между "в ядре, помечена как experimental" и "в ядре отсутствует" чувствуешь?

> Родительская и дочерняя абсолютно идентичны (клон), но в родительскую писАть можно, а вот в дочернюю нет.

А что, "mount --make-r?shared" - не то?

> Честно сказать, всё равно мало что понял.

Что тебе не понятно? Файлоавя система /mnt, которая живет на блочном устройстве /dev/vdb, является read-write, в то время как само устройство является read-only. То есть программа не сможет напрямую писать в блочное устройство в обход файловой системы. А файловая система всегда оставляет следы, то есть сами файлы. Это секьюрити фишка. Теперь понятно?

>ReiserFS4, которая уже почти допилена, только слегка не стабильна уже много лет не могут включить в ядро

бугога. сам же и ответил на свой вопрос

Эта btrfs undelete умеет? Какая вообще умеет такую фишку? Ну бывает же что случайно не то выделишь в потемках и удалил. А вернуть-то как? Хотя бы вот только только удаленное?.. Сори за ламерский вопрос.

> Reiser4 никогда не попадет в ядро, так как она сильно абстрагирована от VFS.

Сам-то понял, что сказал?

> Сам-то понял, что сказал?

Я то понял, а вот ты брат, по ходу не в теме.

VFS Linux: Reiser4 Internal Abstraction Layer

http://kerneltrap.org/taxonomy/term/626

> Я то понял, а вот ты брат, по ходу не в теме.

Похоже, что все же это ты не в теме. Из твоей же ссылки:

Andrew said, "the plugins appear to be wildly misnamed - they're just an internal abstraction layer which permits later feature additions to be added in a clean and safe manner".

>Подмонтировать ту же фс в другое место в режимо ro никак?

Монтировать может и простой пользователь, диплодок ты этакий.

И операции с дочерним устройством, которое по определению только ro, можно неплохо оптимизировать.

>Эта btrfs undelete умеет? Какая вообще умеет такую фишку?

ext4, если уже имплементировали.

>Хотя бы вот только только удаленное?

ext2

а если этот файл кто-либо еще использует, то с помощью fuser можно на любой fs восстановить.

Ты безнадёжен! Читай второе предложение.

Плагины Reiser4 - это как вторая VFS.

The ongoing discussion about the Reiser4 filesystem continues on the lkml. Jeff Garzik discussed the complexity introduced by a plugin layer [story], suggesting it is really a second VFS.

Понятное дело, что эти костыли никому нах не нужны! Нужно использовать стандартную VFS, кот. используют все файловые системы ядра.

> Josef Bacik

Йожин с бажин?

>> Где логика?

>Она будет помечена как experimental, также это было до версии 2.6.28 с ext4.

Вопрос в том, почему рейзер4 не включается в ядро как эксперементальная ?

Несколько лет Линус тормозит этот код, и включает мертвый ещё код другой фс в ядро. При таком подходе скоро бсд-ки будут иметь крутые фс, а линукс будет далеко в Африке.

> Вопрос в том, почему рейзер4 не включается в ядро как эксперементальная ?

1. Bad design (не используется VFS) 2. No support (уже не поддерживается namesys)

>1. Bad design (не используется VFS)

думаю, это нефатальный недостаток.

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

Будем тестировать :)
P.S.
Ну что, зфс капец?

>А еще расскажите как они сделали writeable snapshots!

Я думаю, это всё copy-on-write.

> Важно то, что рейзер в отличие от btrfs просто не нужен. Он не добавляет ничего принципиально нового. Поэтому даже наличие некритичных недостатков привело к такому результату.

Действительно, и там и там файлы и директории, ничего нового. Ну плагины это бесполезные костыли, а экстенты и прочая ересь давно есть в btrfs/zfs, так что reiserfs4 не нужен.

Замечательная логика.

> Jeff Garzik discussed the complexity introduced by a plugin layer [story], suggesting it is really a second VFS.

Ну и зачем ты тут мусолишь очередную туфту, которую выдал Джеф Гарзик? Он так и не смог показать, в каком интерфейсе Reiser4 нарушает субординацию уровней ОС. Может ты за него это сделаешь?

Один из немногих людей, которые никогда не позволяли себе манипулировать непроверенными данными - это Эндрю Мортон. Его сообщения и читай.

какая-то мутная последовательность.

зачем создавать этот subvol если дальше он нигде не фигурирует?

btrfs -S subvol /mnt

echo hello > /mnt/subvol/xxx

зачем было монтировать fs, чтобы только добавить к ней другое устройство?

mount /dev/vdb /mnt

btrfs-vol -a /dev/vdc /mnt

Ты абсолютно безнадёжен!!!

Читай третий абзац, там пишет твой любимый Мортон: http://kerneltrap.org/taxonomy/term/626

...

he added, "the writeout code is ugly, although that's largely due to a mismatch between what reiser4 wants to do and what the VFS/MM expects it to do. then suggested, "I'd say that resier4's major problem is the lack of xattrs, acls and direct-io. That's likely to significantly limit its vendor uptake."

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

Рейзер4 - это кривоподелие, кот. в ядре не будет _никогда_!!! Слова твоего любимого Мортона "code is ugly" переводятся как "уродливый код".

> Эта btrfs undelete умеет? Какая вообще умеет такую фишку? Ну бывает же что случайно не то выделишь в потемках и удалил. А вернуть-то как? Хотя бы вот только только удаленное?.. Сори за ламерский вопрос.

ext2 умеет через mc :)

Есть такое универсальное средство восстановления стёртых данных, называется бэкап...

> Рейзер4 - это кривоподелие, кот. в ядре не будет _никогда_!!! Слова твоего любимого Мортона "code is ugly" переводятся как "уродливый код".

В чём измеряется уродливость кода? "Кривоподелие", ну-ну. В ядре подобных "кривопделиев" куча, и ничего, никто их не выкинул. Одно время говорили, что райзер4 нестабильный и из-за этого его и нет в ядре. Теперь, когда включили сабж в ядро, осталось только "ugly code". Хехе

Тролль тоньше

Такого г-на я не ожидал в "стабильной" версии ядра. Куда катится линукс?

Кажется, понятно - решили пропиарить ФС и найти миллион леммингов для тестирования. Удачи

>Ну плагины это бесполезные костыли

Сами по себе, да.

>а экстенты и прочая ересь

есть в ext4

но это тоже не принципиальное улучшение. У ext4 только udelete является чем-то принципиально новым для пользователя. Остальное только циферки меняет в бенчмарках.

>давно есть в btrfs/zfs

в btrfs/zfs есть контроль записанных данных и много чего еще, чего нет в других fs.

>>Ну плагины это бесполезные костыли

>Сами по себе, да.

Откуда вообще такое мнение? Только потому что из рейзера их не перенесли в Btrfs?

> У ext4 только udelete является чем-то принципиально новым для пользователя.

Вроде как btrfs тоже может undelete. Вот что пишет Chris Mason:

http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg00783.html

- undelete (file and dir)

Undelete is easy but I think best done at a layer above the FS.