LINUX.ORG.RU

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

 , ,


0

0

Линус Торвальдс, после дискуссии в списке рассылки разработчиков ядра Linux, одобрил включение файловых систем Btrfs и Squashfs в состав будущей версии ядра 2.6.29. Патчи Btrfs уже интегрированы в Git-репозиторий ядра, в то время как патчи со Squashfs еще ожидают добавления. По заявлению разработчиков Btrfs, данная файловая система уже достаточно стабильна для начала полномасштабного тестирования внутри ядра Linux.

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

Btrfs - открытая файловая система, разрабатываемая при поддержке компании Oracle и похожая по возможностям на файловую систему ZFS. Теоретический предел дискового раздела файловой системы BTRFS равен 18 эксабайтам. Основные характеристики:

  • Для всех блоков данных и метаданных дополнительно хранятся контрольные суммы.
  • Возможность определения и автовосстановления ошибок, через поддержку copy-on-write режима работы с данными и метаданными (транзакционная файловая система, в которой данные не перезаписываются).
  • Снапшоты, с возможностью записи и изменения данных.
  • Максимальное число файлов - 2^64.
  • Минимальный расход дискового пространства для хранения небольших файлов и индексов директорий.
  • Двойное индексирование дерева каталогов: Btree и TEA hash.
  • Динамическое распределение inode.
  • Подразделы (несколько корней в одной ФС).
  • Быстрая проверка и восстановление ошибок.
  • Функции зеркалирования (Raid0, Raid1 и Raid10) и разнесение на несколько дисков на уровне объектов.
  • Проверка целостности ФС на лету.
  • Эффективные средства инкрементального бэкапа и зеркалирования.
  • Возможность продолжения работы даже при частичном повреждении данных.
  • ACL.
  • Изменение размера ФС на лету, без остановки работы (включая возможность уменьшения размера).

Взято opennet.ru

>>> Подробности

Ответ на: комментарий от alex-w

>И это ты называешь аналогом ZFS? Да ее - btrfs - еще пилить и пилить. ZFS уже оттестирована и вылизана, а btrfs является поделкой на коленке с костылями тут и там.

Она простите во фряхе оттестирована и вылизана или ещё где кроме солярки?

Lonli-Lokli ★★
()
Ответ на: комментарий от frey

>> +1, пулы и снапшоты оттуда же. Не понимаю зачем это при живом LVM. Появилось дублирование функционала.

>Размер тома поменять не проблема, а что с фс на соседних томах? Все ли фс умеют нормальный ресайз в обе стороны?

Так об этом надо думать на этапе выбора ФС, иначе ССЗБ

Lonli-Lokli ★★
()
Ответ на: комментарий от alex-w

> Буквенными метками дисков страдают только две операционки из более чем 50 штук - DOS и Windows. Так что не нужно тут упоминать о "нормальности". Если ты ородясь ничего кроме Windows, Windows, Windows и Linux не видел, то это не значит, что больше ничего нету

Более того, Windows имеет их только для совместимости с ДОС (при желании можно все диски примонтировать в общую иерархию), а в Windows CE и этого нет — всё аккуратно монтируется в подкаталоги как у нормальных людей.

ps. И почему мне никогда не попадаются говорящие капчи?

anonymous
()
Ответ на: комментарий от anonymous

>>Линукс уже не тот.

>ох ты батюшки, Линукс развивается, жалость-то какая, а?

Тебе жалко Линукс? А мне не жалко - вон его сколько Линукса то.

anonymous
()
Ответ на: комментарий от annoynimous

>А перемонтирование с опцией sync на время снятия снапшота не поможет?

sync действует только на ext[2-4], fat, ufs.

anonymous
()
Ответ на: комментарий от F_ract_a1L

>зарегистрирован - только сегодня, а какое отношение это имеет к ядру?

А кокой отношение ты имеешь к ядру?

I3rain
()
Ответ на: комментарий от I3rain

> А кокой отношение ты имеешь к ядру?

Батенька, ты и здесь ошибки делаешь %) Может того, поспать?..

wyldrodney
() автор топика
Ответ на: комментарий от anonymous

Предположим, в lvm есть раздел с reiserfs3 на 50Gb.
Данными занято лишь 20G.
Делаем снапшот.
Какого размера получится снапшот?

anonymous
()
Ответ на: комментарий от sda00

>не прошло и нескольких лет, как компоненты, доступные пользователям openSUSE появились в ванильном ядре. кстати aufs в Зюзе тоже "из короба". так что... поздравим мейнстрим типа....

О, гордые пользователи openSUSE подтянулись. Разочарую - остальные дистрибутивые также могут собирать (и собирают) это модулями.

JackYF ★★★★
()
Ответ на: комментарий от frey

> Размер тома поменять не проблема, а что с фс на соседних томах? Все ли фс умеют нормальный ресайз в обе стороны?

Нет, не все. Уменьшаться не умеют JFS и XFS, и LVM им в этом случае не поможет! LVM нужен для распределения физического пространства, а FS для логического. BTRFS нужна и очень важна для линукса.

anonymous
()
Ответ на: комментарий от anonymous

И если получится 20Gb, то КАК ЭТО РАБОТАЕТ?! Откуда lvm знает структуру фс? А если получится 50Gb, то анонимусу будет грустно.

anonymous
()
Ответ на: комментарий от anonymous

Анонимусу грустно.

Если после этого dd пропустить через gzip, надежда на уменьшение размеров есть?

anonymous
()
Ответ на: комментарий от anonymous

>> Какого размера получится снапшот?

> 50GB
> anonymous (*) (11.01.2009 15:05:44)

А для случая БТР ФС ? Без lvm, но на БТР ФС?

anonymous
()
Ответ на: комментарий от anonymous

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

Эмм... В стародавние времена для того, чтоб одна игрушка думала, что у меня вставлен диск a: с правильным файлом я subst'ом монтировал какую-то директорию с файлом в качестве диска а:/

anonymous
()
Ответ на: комментарий от anonymous

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

madcore ★★★★★
()
Ответ на: комментарий от anonymous

>> А для случая БТР ФС ? Без lvm, но на БТР ФС?

> Если делать снапшот BTRFS то 20GB.
> anonymous (*) (11.01.2009 15:13:20)

Ну наконец-то. Теперь я знаю, зачем оно нужно. Мерси.

anonymous
()
Ответ на: комментарий от KRoN73

> Не-а. ОС должна уметь запускать программы и управлять файлами :)

Ты удивишься, когда узнаешь какие ОСи у нас управляют производственным процессом...

anonymous
()
Ответ на: комментарий от anonymous

>В стародавние времена

по моему, subst в дос был рекордсменом по части глюков и исключений, когда он не работал.

AVL2 ★★★★★
()
Ответ на: комментарий от anonymous

> Если после этого dd пропустить через gzip, надежда на уменьшение размеров есть?

Да, конечно. Но только если раздел/том был перед использованием отформатирован нулями и недавно.

anonymous
()
Ответ на: комментарий от AVL2

> по моему, subst в дос был рекордсменом по части глюков и исключений, когда он не работал.

У меня всегда хорошо работал, без глюков.

Nxx ★★★★★
()
Ответ на: комментарий от wyldrodney

> И да. ЗюЗЯ такая ЗюЗЯ...

Красноглазый задрот такой задрот...

anonymous
()
Ответ на: комментарий от KRoN73

>>а биос может счиатться осью?

>Не-а. ОС должна уметь запускать программы и управлять файлами :)


а биос на форте? файлы/блоки, запускалка процессов/скриптуемый монитор -- существенная разница?

anonymous
()
Ответ на: комментарий от anonymous

> Если делать снапшот BTRFS то 20GB.

а если дописать новый файл и сделать второй снапшот, то те же 20Gb или разница только по изменениям -- этому файлу?

anonymous
()
Ответ на: комментарий от anonymous

>а биос на форте?

Если такой будет и будет иметь средства работы с внешними носителями - то уже тянет на ОС :) Но я в современных компах общего назначения не встречал.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

>ЕМНИП, у популярных буквы дисков ещё у EPOC/Symbian,

О! Точно, про них забыл и еще возможно OS/2 - в ней не помню, если честно

alex-w ★★★★★
()
Ответ на: комментарий от Lonli-Lokli

>Она простите во фряхе оттестирована и вылизана или ещё где кроме солярки?

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

alex-w ★★★★★
()
Ответ на: комментарий от AVL2

> часть программ просто не видела этих подстановок.

Только если эти программы использовали систему защиты от копирования и искали настоящий сидюк для проверки. Во всех других программах все норм.

Nxx ★★★★★
()
Ответ на: комментарий от Nxx

> О! Точно, про них забыл и еще возможно OS/2 - в ней не помню, если честно

OS/2 - естественно, а вообще, что понимается под "буквами дисков", В OpenVMS тоже каждый девайс имеет свое имя и в общую иерархию не входит. Но там используется несколько букв и цифры (аналогично досовскому com1, com2).

Nxx ★★★★★
()
Ответ на: комментарий от KRoN73

Современные биосы по крайней мере понимают некоторые ФС и могут читать/писать туда файлы.

madcore ★★★★★
()
Ответ на: комментарий от anonymous

> Предположим, в lvm есть раздел с reiserfs3 на 50Gb. Данными занято лишь 20G. Делаем снапшот. Какого размера получится снапшот?

Никакого. Снапшоты в LVM организованы по принципу блочного copy-on-write. То есть можно взять терабайтный том и создать к нему 100-мегабайтный снапшот. При первой операции записи блока в изначальный том, изначальная копия данных будет записываться в том снапшота. При попытке чтения блока LVM сначала смотрит на наличие этого блока на снапшотном томе, и если блок там не найден, это будет означать что этот блок не менялся с момента создания снапшота и будет прочитан с оригинального тома. То есть если на томе меняется два десятка файлов из миллиона, то в снапшоте будут сохранены только изначальные копии блоки этих 20 файлов. RTFM.

no-dashi ★★★★★
()
Ответ на: комментарий от AVL2

Прадон, что вклиниваюсь, но для описаной цели subst был вполне пригоден.

Ravana
()
Ответ на: комментарий от no-dashi

> Никакого. Снапшоты в LVM организованы по принципу блочного copy-on-write.

Прежде чем писать, рекомендуется самому почитать!

A wonderful facility provided by LVM is 'snapshots'. This allows the administrator to create a new block device which presents an exact copy of a logical volume, frozen at some point in time.

http://tldp.org/HOWTO/LVM-HOWTO/snapshotintro.html

Слово exact переводится как точный, строгий. Вы описали процесс изменения target volume и сохранения этих изменений во времени.

anonymous
()
Ответ на: комментарий от anonymous

т.е. после восстановления снапшота размер нового тома будет равен размеру исходного тома.

anonymous
()
Ответ на: комментарий от KRoN73

>>а биос на форте?

>Если такой будет и будет иметь средства работы с внешними носителями - то уже тянет на ОС :) Но я в современных компах общего назначения не встречал.

Вроде речь про OpenFirmware

fat_angel ★★★★★
()

Наконец-то Squashfs не придется патчем накладывать!!!!!!!

З.ы. А в livecd уже sqlzma вроде бы..

Slackware_user ★★★★★
()
Ответ на: комментарий от anonymous

Еще один важный момент.

If the snapshot logical volume becomes full it will be dropped (become unusable) so it is vitally important to allocate enough space!

anonymous
()

Переползаю на .29 :) Перевожу хомяк на бтр, ой... 8)

Lumi ★★★★★
()
Ответ на: комментарий от anonymous

> Слово exact переводится как точный, строгий. Вы описали процесс изменения target volume и сохранения этих изменений во времени.

Ну да. Я тут немного неправильно употребил оборот copy-on-write. Следовало бы сказать как-нибудь по другому. Но тем не менее факт остается фактом - под снапшот реально расходуется столько же блоков сколько изменилось на начальном устройстве. Единственное отличие от снапшотов на уровне фс в том, что работает это на другом уровне (устройство, а не файл).

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

> Ну да. Я тут немного неправильно употребил оборот copy-on-write.

Я абсолютно согласен, что в snapshot volume записываются только изменения целевого тома. Но мне кажется, что человека интересует именно выходной результат. После восстановления snapshot'а он получит те же 50GB.

anonymous
()
Ответ на: комментарий от anonymous

>> Ну да. Я тут немного неправильно употребил оборот copy-on-write.

> Я абсолютно согласен, что в snapshot volume записываются только изменения целевого тома. Но мне кажется, что человека интересует именно выходной результат. После восстановления snapshot'а он получит те же 50GB.

Тогда тому человеку нада научится задавать правильные вопросы. На вопрос "какого размера получится снэпшот", ответ будет 50GB. Но на вопрос "сколько места займет снэпшот на диске" ответ будет: "Столько, сколько ты укажишь!"

anonymous
()
Ответ на: комментарий от ptah_alexs

>ZFSкапец?

Увы нет. Btrfs — это практически замена ZFS на Linux, как и Ext4 — долгожданная замена UFS2. Только и всего.

Но, в отличие от UFS2 (год продакшена 2002) и ZFS (год продакшена 2006), файловые системы Linux Ext4 (год продакшена 2008) и Btrfs (год продакшена ??) пока находятся на стадии массового тестирования и экспериментальной стадии внедрения в ядро, соответственно.

iZEN ★★★★★
()
Ответ на: комментарий от tailgunner

>> как и Ext4 — долгожданная замена UFS2
>Ы? Может, ты хотел сказать "аналог"?


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

iZEN ★★★★★
()
Ответ на: комментарий от const86

>Что такое есть в ext4 и ufs2, но нет в других линуксовых фс?

Что общее у Ext4 с UFS2 и нет в других "классических" FS:
1) универсальность;
2) моментальные снапшоты;
3) распределение пространства экстентами, а не целыми блоками.

iZEN ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.