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

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

Контроль записи при помощи чего? CRC? З.Ы. Какая ФС умеет писать данные с помехоустойчивым кодированием (типа Рида-Соломона и прочего)?

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

а правда, что у линукса настолько кривой VFS, что чтобы оно работало быстро и эффективно, автору 'killer fs' пришлось сделать свой велосипед, только горный с 12 скоростями вместо трёхколёсного с квадратными колёсами?

> а правда, что у линукса настолько кривой VFS, что чтобы оно [...]

Тоньше надо.

> а правда, что у линукса настолько кривой VFS

Автору "dead FS" нужно переписать ugly code и замаливать тяжкий грех. А велосипед линуксовой VFS действительно не нужен.

JFS анделит умеет.

> Тоньше надо.

Толще-тоньше. Пойдем к фактам:

VFS не может представить файл как директорию. Т.е., имея файл foo.tar.gz мы не можем обратиться к foo.tar.gz/bar.txt. В reiser4 такие фокусы используются, правда не настолько сурово, чтобы архивы распаковывать на лету, а немного по-другому, более просто — там разная полезная служебная информация подобным методом экспортируется.

А Линус до сих пор не может решить простую задачу с хардлинками на директории. Потому что в VFS нет нормальной поддержки транзакционности, а значит с хардлинками можно двумя mv, которые выполнятся одновременно, завязать файловую систему в узел.

Так вот и вопрос кто тут еще троллит.

> VFS не может представить файл как директорию.

Это необходимо для "быстрой и эффективной работы"?

> Линус до сих пор не может решить простую задачу с хардлинками на директории. Потому что в VFS нет нормальной поддержки транзакционности, а значит с хардлинками можно двумя mv, которые выполнятся одновременно, завязать файловую систему в узел

Афигеть какой недостаток. Знаешь, а еще рут может сделать cat /dev/zero >/dev/sda, запретишь это на уровне VFS?

> Так вот и вопрос кто тут еще троллит.

Это не вопрос.

> VFS не может представить файл как директорию.

Всегда думал, что любой объект в ФС *nix - это файл. Директория - это файл, кот. содержит ссылки на другие файлы, а символ "/" используется для адресации этих директорий. А тут оказывается, цитирую:

"имея файл foo.tar.gz мы не можем обратиться к foo.tar.gz/bar.txt"

Во фре директория - точно файл!

[sns@tree ~/test]$ ls
tashconf taship
[sns@tree ~/test]$ cat .
-�


.u��

...�
taship�/�
tashconf�v�[sns@tree ~/test]$

Как невозможность обращения foo.tar.gz/bar.txt противоречит выражению "любой объект в ФС *nix - это файл"?

Теперь понятнее, спасибо.

Но, всё же, интересно - что помешает пользователю записать что-либо напрямую в /dev/vdb?

И в чём проблема обрезать пользователю права на устройство я тоже не понял:
ivan@niels$ ls -la /dev/sda1
brw-rw---- 1 root disk 8, 1 Янв 13 2009 /dev/sda1
ivan@niels$ cat /dev/sda1
cat: /dev/sda1: Отказано в доступе
ivan@niels$ mount | grep sda1
/dev/sda1 on /mnt/winc type vfat (rw,noexec,nosuid,nodev,showexec,codepage=866,iocharset=utf8,umask=0)
ivan@niels$ echo hello > /mnt/winc/temp/test.txt
ivan@niels$ cat /mnt/winc/temp/test.txt
hello
ivan@niels$

> Это необходимо для "быстрой и эффективной работы"?

Нет. А что, красноглазым нынче уже плевать, что VFS ничего не умеет, зато бы быстро и эффективно работало.

> Афигеть какой недостаток.

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

> Директория - это файл, кот. содержит ссылки на другие файлы, а символ "/" используется для адресации этих директорий.

Читать учимся внимательно и вдумчиво. Не из директории сделать файл, а из файла — директорию. И нету в Linux такого дуализма, не умеет он такого, на что еще триста лет тому назад жаловались авторы AVFS, которым приходится делать это кривым костылем foo.tar.gz#/bar.txt.

>> Это необходимо для "быстрой и эффективной работы"?

> Нет. А что, красноглазым нынче уже плевать, что VFS ничего не умеет, зато бы быстро и эффективно работал

Изначальная претензия была к тому, что линуксовая VFS не умеет работать "быстро и эффективно". Сейчас претензия сменилась на "ничего не умеет"? VFS умеет довольного много, man mount.

>> Афигеть какой недостаток.

> Вы, уважаемый, придуриваетесь или и правда такой?

Я правда такой.

> Вам говорят про невозможность делать хардлинк на директорию.

А я вспоминаю руководства по Unix мохнатых годов, в которых говорилось, что это нафиг не нужно и опасно (даже если сам вызов ln завершился успешно), и спрашиваю - можно привести use-case, когда это необходим именно хардлинк, а симлинк не катит?

> А Вы говорите про то, что можно систему сломать.

Да, это я сглупил - систему сломать хардлинком на каталог довольно трудно - у меня он даже от рута завершается с "Operation not permitted".

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

Очень интересный вывод. Это сколько нового каждая ФС добавила к ядру линукса ? И если уж на то пошло, убрали бы рейзер3. Я первый раз вижу, что есть какие либо иные критерии для ФС кроме скорости и надёжности.

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

Просто зависть разработчиков ядра, отвечающих за фс и/или ext3/ext4 .

>> а правда, что у линукса настолько кривой VFS, что чтобы оно [...]

>Тоньше надо.

Дублирование функциональности, грязный код и прочее - это сферический конь в вакууме. А объективные критерии - скорость и надёжность.

Я использую рейзер4 на домашнем компьютере уже много лет. Раньше рейзер4 по скорости раза в 2 превосходил ext3.

За это время, в результате непрерывного изменения кода ФС, для того,чтобы соответствовать требованиям определяющим включение в ядро, скорость существенно упала.

Вот чистый результат этих требований.

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

>Во фре директория - точно файл!

в linux до 2.4 тоже можно было так делать.

А потом vfs ))

> VFS умеет довольного много, man mount.

Я понимаю что умеет много. Но хотелось бы иметь еще больше, по крайней мере некоторых вещей.

> можно привести use-case, когда это необходим именно хардлинк, а симлинк не катит?

Файл-как-директория. С теми же архивами, с теми же горячо любимыми братьями нашими вантузятниками .cue+.flac и прочими игрушками.

Почитайте историю срачей вокруг Reiser4. Там все так и идет: файл-как-директория (где есть дополнительные файлики со служебной информацией) -> проблемы с хардлинками -> собственные фокусы в reiser4 -> хрен Гансу а не reiser4 в ядре.

>> VFS умеет довольного много, man mount.

> Я понимаю что умеет много. Но хотелось бы иметь еще больше, по крайней мере некоторых вещей.

Если ты тот самый анонимус, то сначала ты утверждал, что у Линукса "кривой VFS", который не умеет "работать быстро и эффективно". А сейчас ты говоришь, что ему просто не хватает вещей, которые ты считаешь нужными. Но никто и не спорит, что VFS есть куда развиваться (она и развивается, AFAIK).

>> можно привести use-case, когда это необходим именно хардлинк, а симлинк не катит?

> Файл-как-директория. С теми же архивами, с теми же горячо любимыми братьями нашими вантузятниками .cue+.flac и прочими игрушками.

Этого просто не понял. Причем тут вообще файл-как-каталог? И чем не катит симлинк, указывающий на смонтированную где-нибудь в другом месте FUSE?

> Почитайте историю срачей вокруг Reiser4

Я читал немного :) Ганс говорил, что ему жестоко не хватает возможностей VFS, но отказался ее дорабатывать :/

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

Судя по заявленным фитчам, оно должно быть как в Solaris - сразу все на btrfs, без lvm, чтобы функционал не дублировать и не мешать оптимальной работе btrfs.

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

Да, надо. На виртуальной машине в Xen и тестировать, репортить, тестировать, репортить...

Когда все будет работать - переезжать постепенно.

Не зря же это dev.

> Эта btrfs undelete умеет?

Насколько знаю - нет. Это security фишка linux файловых систем - гарантированно восстановить нельзя. Если хотите, чтобы гарантированно нельзя было восстановить - используйте shred.

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

rsync, cvs, svn, git, корзина. Зависит от характера данных.

> Ну бывает же что случайно не то выделишь в потемках и удалил.

Удаляй в корзину.

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

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

Что касается домашней порнухи - которая занимает много места и бекапить ее исходя из экономических соображений нецелесообразно - нужно думать прежде чем удалять. За этим при Shift+Del не следует отключать подтверждение удаления.

> Сори за ламерский вопрос.

Ничего страшного. Многие этот вопрос задают. Вот мое видение почему не делают undelete:

Unix системы отличаются строгостью и обоснованностью. Если вам нужна фишка undelete - значит этот undelete должен быть гарантированным, а не "как повезет". В подавляющем большинстве современных файловых систем архитектурно undelete не предусмотрен. Негарантированная его реализация может рассматриваться как дырка в безопасности. Тем более полагаться на undelete опасно - может подвести в любой момент.

На самом деле в Linux есть какие-то средства негарантированного восстановления файлов, которые сводятся к просмотру raw device и поиску фрагментов потерянного файла. Но гораздо проще не испытывать судьбу, а пользоваться бекапами.

Поскольку все *nix пользователи понимают, что бекап - он лучше, чем негарантированное восстановление - поэтому нужды в undelete не возникает.

>> У ext4 только udelete является чем-то принципиально новым для пользователя. > Вроде как btrfs тоже может undelete. Вот что пишет Chris Mason: http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg00783.html

http://article.gmane.org/gmane.linux.file-systems/11944

По примеру ext4: тут не undelete, а просто корзина на уровне файловой системы. То есть реально удаленные данные гарантированно не восстановить (а как иначе?).

undelete, как я его понимаю - возможность легкого, но негарантированного восстановления реально удаленного файла (когда данные еще есть, файла уже нет).

Если эту корзину отключать (а это жалующиеся на отсутствие undelete и делают) - ничего не изменится.

> Какая ФС умеет писать данные с помехоустойчивым кодированием (типа Рида-Соломона и прочего)?

Сдаётся мне, что это более низкоуровневая задача. На сколько помню, на дискетах под каждый байт данных отводилось 14 бит на дискете. На CD тоже, каждый сектор в 2048 байт хранится в ~2500 (не помню точно) байтах. Подозреваю, что и на HDD тоже есть избыточность.

>Ну бывает же что случайно не то выделишь в потемках и удалил.

разве неприятно, что файловые системы воспитывают характер и внимательность человека? :)

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

Размазывание функционала по плагинам резко усложняет поддержку и конфигурацию. Особенно, когда одни плагины начинают цеплять другие. В ядре все это некошерно.

> > Эта btrfs undelete умеет?

> Насколько знаю - нет. Это security фишка linux файловых систем - гарантированно восстановить нельзя. Если хотите, чтобы гарантированно нельзя было восстановить - используйте shred.

А мне вот интересно, что никто не задумывался о возможности восстановления файла _на журналируемых_ ФС с помощью этого самого журнала? Идея проста: удалили файл -> говорим undelete/unerase и на основе данных журнала ищутся сектора -> восстанавливаем файл, где был файл. Это конечно же должно быть реализовано на уровне самой ФС, но это несложно.

Или можно сделать erase-on-write :)

>Я первый раз вижу, что есть какие либо иные критерии для ФС кроме скорости и надёжности.

тогда ext2 лучше всех. Журнал уж точно не нужен.

>undelete, как я его понимаю - возможность легкого, но негарантированного восстановления реально удаленного файла (когда данные еще есть, файла уже нет).

не совсем. undelete это специфический fsck, который смотрит в метаданные fs и пытается вытащить максимум незатертой информации о данных.

Никаких гарантий от undelete не нужно, нужна возможность найти и по выборочно восстановить максимум того, что не было перезаписано.

Подержка undelete на уровне fs могла бы быть в том, что вместо удаления данных о файле их можно было бы только помечать удаленными. Собственно в досовском fat так на примитивном уровне и было.

>Если эту корзину отключать (а это жалующиеся на отсутствие undelete и делают) - ничего не изменится.

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

>Сдаётся мне, что это более низкоуровневая задача

ни в коем разе. низкоуровневый давно уже есть, но он работает в самом устройстве не защищает от перекосов по данным. Например, берешь и вытаскиваешь проводок записи из флоповода. Программа пишет на диск, флоповод говорит, все хорошо и все. а при чтении полный мусор.

>Это security фишка linux файловых систем - гарантированно восстановить нельзя.

Незатертые данные можно восстановить. К секурности это не имеет никакого отношения.

>Если хотите, чтобы гарантированно нельзя было восстановить - используйте shred.

логично.

>В подавляющем большинстве современных файловых систем архитектурно undelete не предусмотрен.

undelete, это просто часть инструментария по обслуживанию fs.

как fsck, resize или дефрагментатор

> ни в коем разе. низкоуровневый давно уже есть, но он работает в самом устройстве не защищает от перекосов по данным. Например, берешь и вытаскиваешь проводок записи из флоповода. Программа пишет на диск, флоповод говорит, все хорошо и все. а при чтении полный мусор.

Хорошо. Тогда более высокоуровневая. Кодируйте свои данные с избыточностью, достаточной для восстановления после сбоев. А ФС опять же ни к чему нагружать этой функцией. Она не всем нужна.

>Хорошо. Тогда более высокоуровневая. Кодируйте свои данные с избыточностью, достаточной для восстановления после сбоев. А ФС опять же ни к чему нагружать этой функцией. Она не всем нужна.

прально. и раиды со снепшотами тоже пускай будут прямо в приложениях. Оракл же живет на raw-партициях, пусть все так пашут...

>>Я первый раз вижу, что есть какие либо иные критерии для ФС кроме скорости и надёжности.

>тогда ext2 лучше всех. Журнал уж точно не нужен.

Ты говорил о скорости, а я о скорости + надёжности. И тогда журнал уже точно нужен.

> Никаких гарантий от undelete не нужно, нужна возможность найти и по выборочно восстановить максимум того, что не было перезаписано.

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

> и раиды со снепшотами тоже пускай будут прямо в приложениях.

На сколько я разумею, их как раз засунули в btrfs :)

>Ты говорил о скорости, а я о скорости + надёжности. И тогда журнал уже точно нужен.

Журнал надежности не добавляет. Это не раид.

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

корзина полезна в 0.0000001%, в хомяке жирного тупоголового юзера.

А undelete полезен как последний довод. Бывают ошибки в софте, бывают ошибки оператора.

>На сколько я разумею, их как раз засунули в btrfs :)

как и проверку целостности данных. Выше по треду предложили эту проверку сделать прямо в приложениях. Каким образом в приложении верифицировать служебные структуры самой фс, осталось за кадром...

>Я использую рейзер4 на домашнем компьютере уже много лет. Раньше рейзер4 по скорости раза в 2 превосходил ext3.

А жену свою, случаем, много лет назад не того?

>Любителям красивого кода надо в музей современных искусств, там полно абстрактных произведений, что нибудь явно себе найдёт по вкусу.

А любителям быдлоподелий от маньков-убийц надо в тюрьму к смертникам.

>тогда ext2 лучше всех. Журнал уж точно не нужен.

В линюкс есть лишь одна нормальная и оптимальная ФС по скорости и надежности - это jfs. Остальное либо менее надежное, либо жрет ресурсы, либо тормозит.

Судя по всему, btrfs может стать отличной альтернативой.

Любители ФС имени Джека Потрошителя пусть лопнут от зависти, что их быдлокодер не смог протянуть свое быдлоподелие в ядро.

> корзина полезна в 0.0000001%, в хомяке жирного тупоголового юзера.

За исключением 0.0000001% ей никто не пользуется?

> А undelete полезен как последний довод. Бывают ошибки в софте, бывают ошибки оператора.

Какой софт удаляет документы? Корзина именно от ошибки оператора страхует.

Вот смотри синтетический пример: написали мы оба речь для начальника, чтобы он на конференции выступил. Ему не понравилось и он взял речь третьего человека. Я осознаю, что документ погоды на винте не сделает, но мешается и удаляю его в корзину. Вы же просто удаляете файл. Тут начальник осознал, что был не прав и просит принести ему наши тексты посмотреть еще раз.

1) Я восстановил файл из корзины 2) Вы попробовали undelete - но ничего не вышло.

Теперь по поводу "документы хранятся вечно" - да, при сумме дискового пространства не десктопе немногим менее терабайта я не удаляю безвозвратно все, что было связано с работой. А работа с мультимедиа не связана - значит речь идет о довольно малых объемах (думаю как и у большинства). Утерю домашней коллекции порно трагедией не считаю.

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

почему не LZO?

>Вот смотри синтетический пример: написали мы оба речь для начальника, чтобы он на конференции выступил. Ему не понравилось и он взял речь третьего человека. Я осознаю, что документ погоды на винте не сделает, но мешается и удаляю его в корзину. Вы же просто удаляете файл. Тут начальник осознал, что был не прав и просит принести ему наши тексты посмотреть еще раз.

зачем лищние сущности? ну сделал папку "разногавно" или "корзина" и складывай туда все, что жаль удалять или просто нет уверенности.

>Я осознаю, что документ погоды на винте не сделает, но мешается и удаляю его в корзину. Вы же просто удаляете файл.

Не надо удалять файлы, которые еще могут пригодится. Тем паче, что места они много занять в принципе не могут.

>Теперь по поводу "документы хранятся вечно" - да, при сумме дискового пространства не десктопе немногим менее терабайта я не удаляю безвозвратно все, что было связано с работой.

их вообще удалять не надо. их надо архивировать и индексировать.

>А работа с мультимедиа не связана - значит речь идет о довольно малых объемах (думаю как и у большинства). Утерю домашней коллекции порно трагедией не считаю.

Дело в том, что корзина подменяет операцию удаления. Причем в 999 случаях из 1000 удаление не предполагает восстановления. Поэтому корзина теряет смысл. Вместо помощи она просто вдвое увеличивает количество операций удаления. Люди очень быстро привыкают удалять файлы и из корзины на автомате и вперед и в нужный момент она им уже не помогает. можно удалить файл, потому что кончилось место и забыть очистить корзину. если при этом пошел процесс, которому как раз нужно место, он упадет и таким образом корзина провоцирует нестабильность в работе.

> Размазывание функционала по плагинам резко усложняет поддержку и конфигурацию. Особенно, когда одни плагины начинают цеплять другие.

Такой вывод либо от незнания, либо от отсутствия соответствующей культуры, приводящему к заключениям "раз ни у кого нет, то плохо". Что значит "цеплять"? В ядре запрещено функции вызывать?

> В ядре все это некошерно.

Это как? Код ядра должен быть писан программистами Израиля?

Сколько лицемерия в треде. "Плодить виндузятников", бекапы, корзина.. Откуда ж вы вообще такие вылезли? При чем здесьвендузятники, тут уже говорили о софте с функцией удаления файлов (его куча), в скрипте можно накосячить, кто-нибудь из родственников/етц наделает делов — И всё ушло мимо корзины. Ситуаций много, вы их только признавать не хотите. Бекапить всё — тут кто-то так делает? Вместе с фильмами/музыкой, и прочим.

Анделит нужен для десктопной ОС, идеально — как уже где-то здесь писали, возможность монтирования ФС с опциями --безопасноеудалениевыкл и --безопасноеудалениевкл, для разных вариантов применения.

>>Я использую рейзер4 на домашнем компьютере уже много лет. Раньше рейзер4 по скорости раза в 2 превосходил ext3.

>А жену свою, случаем, много лет назад не того?

Видишь ли, ты наверное из тех, кто думает, что подробности семейной жизни обсуждаются на форумах, да еще с такими как ты. Тебе явно надо пожить в нормальной семье и повзрослеть в нормальной обстановке

>>Любителям красивого кода надо в музей современных искусств, там полно абстрактных произведений, что нибудь явно себе найдёт по вкусу.

>А любителям быдлоподелий от маньков-убийц надо в тюрьму к смертникам.

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

Такие как ты после проигрыша в финальной игре говорят о том "зато наши перцы играли красивее".

>>Ты говорил о скорости, а я о скорости + надёжности. И тогда журнал уже точно нужен.

>Журнал надежности не добавляет. Это не раид.

Но я не говорил о сохранении только лишь данных :-)

>Такой вывод либо от незнания, либо от отсутствия соответствующей культуры, приводящему к заключениям "раз ни у кого нет, то плохо".

плагинов вокруг мало?

>Что значит "цеплять"? В ядре запрещено функции вызывать?

Завис в ядре и юзерспейсе несколько отличаются по своим последствиям.

>Это как? Код ядра должен быть писан программистами Израиля?

В Израиле - да. Также разрешено писать по православному канону.

>Но я не говорил о сохранении только лишь данных :-)

я тоже об этом не говорил. журнал не добавляет надежности сохранения ни данных ни метаданных. Наоборот, он немного ее снижает, поскольку к ошибкам в данных добавляются ошибки в самом журнале.

Журнал упрощает только сверку непротиворечивости данных. Это чистой воды сервис.

> прально. и раиды со снепшотами тоже пускай будут прямо в приложениях. Оракл же живет на raw-партициях, пусть все так пашут...

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

> Если ты тот самый анонимус, то сначала ты утверждал, что у Линукса "кривой VFS", который не умеет "работать быстро и эффективно".

Нет, не тот.

> Этого просто не понял. Причем тут вообще файл-как-каталог?

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

> Ганс говорил, что ему жестоко не хватает возможностей VFS, но отказался ее дорабатывать :/

Угу.