Для Linux доступна нативная поддержка файловой системы ZFS

iZEN> Там... UFS2 с Soft Updates обычно с мультимедийными данными.

Не ври - Windows не поддерживает UFS.

И?

>А вот, кстати, для хранения всякой мультимедии, ну фильмов, например, лучше UFS2+SU или ZFS?

А вот для хранения всякой мультимундии лучше UFS2+SU, так как менее требовательна к железу, к которому подцепляется жёсткий диск с ней.

Для важных данных и архивов лучше конечно ZFS, так как обеспечивается сквозная целостность данных на пути память-HDD.

> BTRFS в продакшне уже.

Где? У тебя чтоли?

> Под Windows нет даже сторонней поддержки ZFS. Так что iZEN ну не осилит принести флэшку с ZFS.

А вдруг он к FUSE под Windows поддержку ZFS прикрутил?

> а с каких пор raw partitions под БД это уже не Ъ?

Со времен реализации direct io (лет 6-7).

>> а с каких пор raw partitions под БД это уже не Ъ?

Со времен реализации direct io (лет 6-7).

Поясните? Как Direct IO поможет избежать выполнения кода файловой системы?

> Как Direct IO поможет избежать выполнения кода файловой системы?

Никак. Но претензия к ФС (ext[23]) была не в том, что она медленная, а в том, что она кэширует то, что всё равно кэширует СУБД. Direct IO избегает этого двойного кэширования.

>> Как Direct IO поможет избежать выполнения кода файловой системы?

Никак. Но претензия к ФС (ext[23]) была не в том, что она медленная, а в том, что она кэширует то, что всё равно кэширует СУБД.

Эта претензия была только в твоей голове. В вопросе вопрошающего никаких претензий на этот счет не было.

Direct IO избегает этого двойного кэширования.

А raw-доступ избегает ненужного оверхеда ФС вообще.

>> Но претензия к ФС (ext[23]) была не в том, что она медленная, а в том, что она кэширует то, что всё равно кэширует СУБД.

Эта претензия была только в твоей голове.

Ахренеть, телепаты вернулись из отпуска.

В вопросе вопрошающего никаких претензий на этот счет не было.

На вопрос вопрошающего я ответил «Никак». В отличие от тебя, я не умею читать мысли и стараюсь объяснять свои ответы.

А raw-доступ избегает ненужного оверхеда ФС вообще.

Капитан, мы всегда вам рады.

>> В вопросе вопрошающего никаких претензий на этот счет не было.

На вопрос вопрошающего я ответил «Никак». В отличие от тебя, я не умею читать мысли и стараюсь объяснять свои ответы.

Я про другой вопрос, о великий Объясняющий Свои Ответы.

А именно вот про этот: «а с каких пор raw partitions под БД это уже не Ъ?»

Так что расслабься, чувак.

ЗЫ:

Эмулятор-то уже качаешь?

>> А как там сейчас дела с Btrfs?

Всё пучком. Что конкретно интересует?

Куда пропал с ответами? Повторяю вопрос:

Работать, когда заканчивается место, она уже научилась? Учитывать, что место уменьшилось, когда один из нескольких дисков убрали?

Работать, когда заканчивается место, она уже научилась?

Да, научилась, вроде

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

Не знаю, что в виду имеется, но теперь все delayed allocation сначала пишутся на диск перед получением снимка (полагаю, тот же механизм работает и для изменения размера subvolume).

Вообще я смотрю на btrfs и она мне нравится. За одним исключением: непонятно, зачем они тянут внутрь ФС еще и управление физическими носителями. Если со снимками понятно — ФС лучше всего знает, какие блоки заняты и чем, то управление физическими носителями лучше было бы оставить в распоряжение LVM. Впрочем, время рассудит.

AВИМ

> Да, научилась, вроде

Хм. Надо посмотреть проверить.

Не знаю, что в виду имеется, но теперь все delayed allocation сначала пишутся на диск перед получением снимка (полагаю, тот же механизм работает и для изменения размера subvolume).

имеется ввиду то, что полгода назад было так: создаем ФС на трех дисках, монтируем, смотрим сколько места, говорит, что места как на трех дисках; убираем один диск, смотрим, говорит что места по-прежнему как на трех дисках, убираем еще один диск, говорит что места все еще как на трех дисках, пытаемся занять все место - накрывается медным тазом. Пробовал на имиджах, выложенных где-то у Криса (ссылки есть на btrfs wiki) Так что это не связано со снимками и subvolume, скорее с чанками и учетом.

Вообще я смотрю на btrfs и она мне нравится.

А ZFS - не?

За одним исключением: непонятно, зачем они тянут внутрь ФС еще и управление физическими носителями. Если со снимками понятно — ФС лучше всего знает, какие блоки заняты и чем, то управление физическими носителями лучше было бы оставить в распоряжение LVM. Впрочем, время рассудит.

Дело в том, что BTRFS, как и ZFS, к сожалению содержит в своем названии аббревиатуру FS, в то время как обе являются больше, чем ФС - обе являются системами управления хранением данных. И это FS сбивает с толку - люди начинают применять имеющиеся представления о ФС, и происходит разрыв шаблона.

Управление физическими носителями внутри BTRFS/ZFS позволяет им точнее контролировать избыточность данных и метаданных, и использовать знания об этой избыточности для исправления ошибок при наличии контроля целостности.

Можно, конечно, оставить управление физическими носителями в LVM, но тогда для достижения подобной функциональности придется придумывать и реализовывать side-band интерфейсы для взаимодействия BTRFS и LVM, что может быть не всегда удобно и надежно.

>Вообще я смотрю на btrfs и она мне нравится. За одним исключением: непонятно, зачем они тянут внутрь ФС еще и управление физическими носителями.

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

С появлением Btrfs, годной к продакшену, LVM становится как бы дублирующим звеном. Вернее, LVM будет нужен только для HAST-фич. Тогда остальная функциональность LVM нужна будет только для унаследованных ФС, а значит будет опять «воз и маленькая тележка». Зоопарк.
— деградация целевого использования налицо.

GEOM на FreeBSD является неотъемлемой частью инфраструктуры блочных устройств, в том числе для ZFS.
— налицо функционально- и ортогонально-гибкий замысел реализации.

Ну и зря дискуссию потерли..

> Со времен реализации direct io (лет 6-7).

ну да, возможность direct io есть, а какой профит хранить БД в файлах вместо сырой партиции? возможность копирования отдельных файлов с таблицами — весьма сомнительный профит

сдается мне, что БД получше сможет раскидать данные по партиции, чем ФС

Я ж не виноват, что дискуссия перемежалась бросками какашек. Да, было жалко.

> С появлением Btrfs, годной к продакшену, LVM становится как бы дублирующим звеном

Возможно. Но пока ни btrfs, ни даже ZFS не показали, что их подход лучше разделения по уровням FS/LVM (кроме снапшотов, пожалуй), так что было ли это правильным решением или нет, еще неясно.

Тогда остальная функциональность LVM нужна будет только для унаследованных ФС, а значит будет опять «воз и маленькая тележка».

По крайней мере, обкатаны нужные технологии и получен опыт. Кроме того, когда появился production LVM и когда ZFS (вовсе еще не production)? Определенно, еще слишком рано говорить, что ZFS лучше существующих решений, хотя бы потому, что масштабы применения пока несравнимы.

GEOM на FreeBSD является неотъемлемой частью инфраструктуры блочных устройств, в том числе для ZFS.

— налицо функционально- и ортогонально-гибкий замысел реализации.

Не распарсил.

>Я ж не виноват, что дискуссия перемежалась бросками какашек. Да, было жалко.

Да ладно, какие там какашки.. Там же всем все показалось

Что дает эта файловая система десткопным Линуксам?

> Там же всем все показалось

Не всем :)

> Стоит заметить, что поддержана будет осуществляться

Стоит заметить, что поддержка будет осуществляться

fxd.

> Но пока ни btrfs, ни даже ZFS не показали, что их подход лучше разделения по уровням FS/LVM (кроме снапшотов, пожалуй),

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

Хотите пример? Одной из причин, почему Solaris называли Slowaris был STREAMS-based сетевой стек, в котором все было по уровням, можно было встраивать свои STREAMS-модули между другими - в общем, все в строгом соответствии с концепцией разделения на уровни, модульности и гибкости. И это все удовлетворительно работало пока процессоров было мало, и скорости были <= 10MBit/s. С ростом скоростей и количества процессоров стало понятно, что мсштабируется это прямо скажем не очень. В то же время в линуксе не было этого тяжелого наследия SVr4 в виде STREAMS-based сетевого стека, так что то, что создавалось - создавалось в соответствии с современными реалиями. Что сейчас - в Solaris'е сетевой стек переписан и работает теперь быстро и масштабируется хорошо. Но совместимость со STREAMS сохранена, и если попытаться засунуть в стек STREAMS-модуль, то вернутся в какой-то мере и «прелести» STREAMS.

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

> Не всем :)

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

Единственная моя point of concern — это то, что код ФС, в который впихнут помимо необходимых вещей еще и кучу «плюшек», вроде того же управления носителями, становится уязвимым к разного рода ошибкам, которых и без этого немало было, есть и будет. В конце-концов, декомпозиция задачи на относительно независимые блоки один из лучших способов понизить ее сложность и тут подход zfs с запихиванием всего и вся в код мне совсем не нравится.

Ну как бы прожорливость zfs по памяти это подтверждает — в памяти болтается куча кода, которая, скорее всего ни в одном случае не нужна _вся на 100%_

Потому что не туда смотрите. Смотреть надо в сторону распределенных хранилищ, для которых пулы в сотни и тысячи терабайт — нормальное явление. Вроде ceph (добавленная в 2.6.34). Помнится, что-то такое редхат еще имеет и даже продает.

Возможно. Но пока ни btrfs, ни даже ZFS не показали, что их подход лучше разделения по уровням FS/LVM (кроме снапшотов, пожалуй), так что было ли это правильным решением или нет, еще неясно.

С луны свалился? Снапшоты — это следствие механизма CoW, в них ничего удивительного нет. Главное в этих ФС то, что есть очень гибкое управление томами и распределение как вычислительных, так и ресурсов хранилищ под данные, чего нет в традиционных подходах к созданию и поддержанию групп томов.

Кроме того, когда появился production LVM и когда ZFS (вовсе еще не production)?

Статьи о первом (вроде стабильном) LVM датируются 2002-2003 годом (когда Ext3 только-только начинала свой разбег в продакшен). Википедия говорит, что «На 18 сентября 2006 года существовало две версии: первая, стабильная и испытанная, используется преимущественно для ядра Linux 2.4 и OS/2, и LVM2 для ядра 2.6 (её также можно использовать для ядра 2.4, но с патчем).». Касательно ZFS: «ZFS была спроектирована и создана командой Sun Microsystems, лидером которой является Джеф Бонвик (Jeff Bonwick). Файловая система была анонсирована 14 сентября 2004 года. [2] Исходный код для финального релиза был интегрирован в главную ветку разработки Solaris 31 октября 2005 года [3] и реализован как часть 27-й сборки OpenSolaris 16 ноября 2005 года. Sun заявила, что ZFS была интегрирована в 6/06 обновление для Solaris 10 в Июне 2006, по прошествии одного года с момента открытия сообщества OpenSolaris.» Выходит, ZFS в продакшене ДОЛЬШЕ, чем LVM2.

«Поддержана» так и осталось.

Ну и вообще в целом это, на мой взгляд, не вполне корректное отражение ситуации. Оно будет жить вне ядра в виде отдельного модуля, так корректнее, на мой взгляд, ибо патчей в собственно порте ZFS нет, а патч в Solaris Porting Layer - примерно по 100 строк как для ядра FC11, так и RHEL5.

Ты хоть по ссылкам ходил, или как настоящий Ъ скопипастил новость и по ссылкам даже не заглядывал?

> И вообще, почему если ломка интерфейсов в ядре считается полезной, такой же принцип не применяется и к другим интерфейсам в системе?

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

> Потому что не туда смотрите. Смотреть надо в сторону распределенных хранилищ, для которых пулы в сотни и тысячи терабайт — нормальное явление. Вроде ceph (добавленная в 2.6.34). Помнится, что-то такое редхат еще имеет и даже продает.

Блин, распределенные хранилища это хорошо, но это не отменяет необходимости в хороших локальных файловых системах. Тот же X4540 - вполне себе интересный узел такого распределенного хранилища, в который уже сейчас напихивается 48Т дисков, а с дисками по 2Т будет почти 100Т. Представляете себе fsck для такого объема? Я - нет. Ну а дальше, на мой вгляд, перспективнее вещи типа стандартизируемый pNFS, ибо открытый стандарт в таком деле - это важно.

в OS X Server поддержка ZFS появилась раньше линукса

Единственная моя point of concern — это то, что код ФС, в который впихнут помимо необходимых вещей еще и кучу «плюшек», вроде того же управления носителями, становится уязвимым к разного рода ошибкам, которых и без этого немало было, есть и будет.

Можно подумать, что если все поделить, то ошибок автоматически станет меньше. Они останутся, но просто часть будет в ФС, часть - в LVM

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

А вы пробовали заглядывать в код ZFS или думаете, что там один такой большой файл zfs.c, в который запихано все на свете? Там вполне себе есть свои уровни - из крупных можно назвать ZPL, DMU, SPA, - которые в свою очередь тоже вполне себе модульные.

Ну как бы прожорливость zfs по памяти это подтверждает — в памяти болтается куча кода, которая, скорее всего ни в одном случае не нужна _вся на 100%_

А про прожорливость по памяти - у вас это из собственного опыта или из интернета?

Куча кода, кстати, не такая уж и большая, вот смотрите (для кода в ядре на сегодня):

> c_count -l -w 64 linux-2.6.34/fs/btrfs/*[ch]
...
  6919	lines had comments        12.6 %
    42	comments are inline       -0.1 %
  6745	lines were blank          12.3 %
  1016	lines for preprocessor     1.9 %
 40120	lines containing code     73.3 %
 54758	total lines              100.0 %

>bin/c_count -l -w 64 usr/src/common/zfs/*[ch] usr/src/uts/common/sys/fs/zfs.h usr/src/uts/common/fs/zfs/*[ch] usr/src/uts/common/fs/zfs/sys/*[ch]
...
 22115	lines had comments        21.7 %
  1602	comments are inline       -1.6 %
 14128	lines were blank          13.8 %
  3602	lines for preprocessor     3.5 %
 63790	lines containing code     62.5 %
102033	total lines              100.0 %

Что мы видим? В btrfs из 54758 строк непосредственно кода - 40120 строк, в ZFS - 63790 строк кода из общего количества в 102033.

Да, бывает, что RAID-Z не используется, вот размер кода, специфичного для RAID-Z:

> c_count -l -w 64  usr/src/uts/common/fs/zfs/vdev_raidz.c
   2146   830   |usr/src/uts/common/fs/zfs/vdev_raidz.c
----------------
  2146   830    total lines/statements

   599	lines had comments        27.9 %
    27	comments are inline       -1.3 %
   297	lines were blank          13.8 %
    24	lines for preprocessor     1.1 %
  1253	lines containing code     58.4 %
  2146	total lines              100.0 %

Всего 1253 строки кода для реализации RAID-Z с одним, двумя и тремя дисками для четности.

Если посмотреть на LVM, то увидим следующее:

> c_count -l -w 64 linux-2.6.34/drivers/md/*[ch]
...
  7679	lines had comments        16.8 %
   512	comments are inline       -1.1 %
  6731	lines were blank          14.8 %
   907	lines for preprocessor     2.0 %
 30828	lines containing code     67.6 %
 45633	total lines              100.0 %

Если просуммировать btrfs и LVM, то получится уже больше кода, чем в ZFS, как по общему количеству строк, так и по количеству строк собственно кода.

Так что расхожее утверждение про монструозность кода ZFS, как мне кажется, не имеет под собой оснований.

Черт, забыл LORCODE включить, может кто-нибудь грохнуть корявое сообщение?

Если еще учесть, что очень часто в Линуксе используется одновременно несколько файловых систем, то кода, болтающегося в памяти, окажется еще больше, вот статистика для ext3:

> c_count -l -w 64 linux-2.6.34/fs/ext3/*[ch] linux-2.6.34/fs/jbd/*[ch]
...
  5668	lines had comments        24.1 %
    87	comments are inline       -0.4 %
  2530	lines were blank          10.7 %
   491	lines for preprocessor     2.1 %
 14965	lines containing code     63.5 %
 23567	total lines              100.0 %

вот для ext4:

> c_count -l -w 64 linux-2.6.34/fs/ext4/*[ch] linux-2.6.34/fs/jbd2/*[ch]
...
  9564	lines had comments        23.1 %
   392	comments are inline       -0.9 %
  4532	lines were blank          11.0 %
  1253	lines for preprocessor     3.0 %
 26391	lines containing code     63.8 %
 41348	total lines              100.0 %

вот для XFS:

> c_count -l -w 64 linux-2.6.34/fs/xfs/*[ch]
...
 25100	lines had comments        33.2 %
  4851	comments are inline       -6.4 %
  6425	lines were blank           8.5 %
  4012	lines for preprocessor     5.3 %
 44935	lines containing code     59.4 %
 75621	total lines              100.0 %

>> И вообще, почему если ломка интерфейсов в ядре считается полезной, такой же принцип не применяется и к другим интерфейсам в системе?

Потому что в других случаях вместо ломки интерфейсов может получиться ломка форматов данных; и потому, что ломка интерфейсов в ядре затрагивает только узкий круг системных прогеров

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

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

> Одной из причин постоянной ломки интерфейсов в ядре называется необходимость делать из правильно

Никто точно не знает, какие интерфейсы - правильные :)

Ну вот почему бы это не распространить на интерфейсы в стеке хранения данных? Он ведь тоже весь в ядре?

Есть разница между, с одной стороны, реализацией спинлока, внутренностями device model и интерфейсом обработчика прерываний, и дисковыми структурами. Первые в головах у относительно небольшого числа людей; вторые - у гораздо большего количества людей, да еще и на дисках (совместимы ли форматы LVM и внутреннего менеджера томов ZFS?).

Хотя читаю вот про Ceph - возможно, уровень интерейса block device уже пора поднять.

> Никто точно не знает, какие интерфейсы - правильные :)

Ну так никто и не заставляет новые интерфейсы немедленно объявлять стабильными. В ZFS интерфейсы ZPL <=> DMU <=> SPA хотя и существуют, но не являются (пока, во всяком случае) публичными/стабильными. Так что возможность их совершенствовать остается.

Есть разница между, с одной стороны, реализацией спинлока, внутренностями device model и интерфейсом обработчика прерываний, и дисковыми структурами.

Ну есть, ну и что? И те, и другие - в ядре. И речь идет даже не про дисковые структуры.

совместимы ли форматы LVM и внутреннего менеджера томов ZFS?

Однозначно нет. А зачем тут нужна совместимость? Я теряюсь в догадках

>> Есть разница между, с одной стороны, реализацией спинлока, внутренностями device model и интерфейсом обработчика прерываний, и дисковыми структурами.

Ну есть, ну и что? И те, и другие - в ядре.

Тогда вопросов нет :)

совместимы ли форматы LVM и внутреннего менеджера томов ZFS?

Однозначно нет. А зачем тут нужна совместимость?

Перейти на ZFS, сохранив тома.

>>> совместимы ли форматы LVM и внутреннего менеджера томов ZFS?

Однозначно нет. А зачем тут нужна совместимость?

Перейти на ZFS, сохранив тома.

Не, не получится. У ZFS даже нет специальных средств миграции с UFS.

Собственно, и концепции менеждера томов в привычном смысле да и самих томов там нет. Весь ввод-вывод производится в виртуальные устройства, а зеркало и RAID-Z - это просто разные классы виртуальных устройств, группирующих несколько физических устройств по определенным правилам. Физические устройства могут быть такими виртуальными устройствами и сами по себе.

> Надо допиливать то что есть, а не тянуть всяку каку в рот 8)

допиливай, что тебе мешает? Неужели этот порт ZFS?

Глядя на btrfs project ideas, становится очевидно, что ребятам странным образом приходят в голову иди, уже реализованные в ZFS. NIH-синдром?

>А вдруг он к FUSE под Windows поддержку ZFS прикрутил?

ага, с помощью клея

> zfs вне линукса не нужна

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

Что, иЗен замонстрячил клей для склеивания виндоус IFS с Солярисным VFS? Правда чтоли? Да иЗен просто монстр какой-то получается

> Куда пропал с ответами?
Выходные были.

Работать, когда заканчивается место, она уже научилась?

Уточни, сколько в % считается под «заканчивается место».

>Что, иЗен замонстрячил клей для склеивания виндоус IFS с Солярисным VFS?

ага, на жабе, с помощью клея

>> Работать, когда заканчивается место, она уже научилась?

Уточни, сколько в % считается под «заканчивается место».

Ну скажем она себя ведет после 80%, после 90%, после 95% заполненности - скорость записи, к примеру.

Там были глобальные проблемы с ENOSPC, но судя по коммитам какие-то подвижки на эту тему были за последние полгода.

Ну и учет пространства при удалении дисков - раньше оно забывало уменьшить емкость и забавно накрывалось медным тазом при попытке использовать всю «имеющуюся» емкость.

> ага, на жабе, с помощью клея

прям рекурсия получается - клей на жабе с помощью клея

> Ну скажем она себя ведет после 80%, после 90%, после 95% заполненности - скорость записи, к примеру.
У меня сейчас на одной машинке 500G с малонужным мусором заполнено на 79%
Скорость записи падает, но я не уверен, что это связано именно с заполненностью. После 90% или около того, что-либо писать туда уже нереально. FS делалась ещё во времена -dev, более свежесделанные ведут себя более корректно. При чеканьи пока ещё ни одна в хлам не превратилась.

Там были глобальные проблемы с ENOSPC, но судя по коммитам какие-то подвижки на эту тему были за последние полгода.

Свежей у меня под рукой нет. В ранних эта проблема есть.

http://git.zen-kernel.org/