> Какие есть ещё ФС, с реализованным Copy-on-Write, снапшотами автомитеческой балансировкой нагрузки/стриппингом между томами и crc?

Есть lvm с реализованным copy-on-write, снапшотами, возможностью организации raid и реализованными в raid-5 контрольными суммами и восстановлением ошибок (в случаях когда это теоретически возможно).

и все это работает одновременно, имеет простой в использовании интерфейс и может быть изменено на лету (во время работы)?

мне действительно интересно как в lvm работает аналог zfs clone, zfs rollback, zfs allow (aka delegation)

да и что-то мне подсказывает, что в lvm не мгновенные snapshot'ы

>и все это работает одновременно, имеет простой в использовании интерфейс и может быть изменено на лету (во время работы)?

А где можно посмотреть скриншоты?

>> Какие есть ещё ФС, с реализованным Copy-on-Write, снапшотами автомитеческой балансировкой нагрузки/стриппингом между томами и crc?

>Есть lvm с реализованным copy-on-write, снапшотами, возможностью организации raid и реализованными в raid-5 контрольными суммами и восстановлением ошибок (в случаях когда это теоретически возможно).

Это не относится к ФС. Я специально несколько раз упомянул в вопросе ФС. И попросил не советовать костыли. Конечно, lvm поддерживает copy-on-write. Только это совсем не то, что подразумевается в ФС (так как lvm понятия не имеет ни о каких файлах).

Так что остаётся либо ZFS+solaris, либо ждать чего-нить (например, btrfs...)

> да и что-то мне подсказывает, что в lvm не мгновенные snapshot'ы

А ты проверь.

> > Есть lvm с реализованным copy-on-write, снапшотами, возможностью организации raid и реализованными в raid-5 контрольными суммами и восстановлением ошибок (в случаях когда это теоретически возможно).

> Это не относится к ФС

А это и не должно относиться к уровню ФС. Управление хранением - функция LVM.

>да и что-то мне подсказывает, что в lvm не мгновенные snapshot'ы

это что-то - голоса или вещества очевидно. лоровские бздуны и солнцефилы в воздействии их уже неоднократно были замечены

> А это и не должно относиться к уровню ФС. Управление хранением - функция LVM.

а хранится, простите, что? не файлы? может ты объяснишь зачем нужно это разделение? много ли у тебя vm с разными fs на них? не геморно ли держать такой зоопарк?

у большинства все равно 1:1, т.е. на один volume одна filesystem.

> может ты объяснишь зачем нужно это разделение? много ли у тебя vm с разными fs на них?

Хватает. Есть как минимум сырые устройства, ext2, ext3 и xfs.

> Хватает. Есть как минимум сырые устройства, ext2, ext3 и xfs.

сырые устройства? на том же volume, что и ext2/ext3/xfs? что-то не верится.

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

так сколько у тебя volume'ов, где находится несколько разных fs? или каждая на своем volume? если да, то зачем разделение уровней? если нет, то зачем тебе volume manager вообще?

>> может ты объяснишь зачем нужно это разделение? много ли у тебя vm с разными fs на них?

> Хватает. Есть как минимум сырые устройства, ext2, ext3 и xfs.

А знаешь, почему у тебя их несколько? Потому, что ни одна из этих недо-ФС не является достаточно мощной и удобной для решения всех задач. Если бы в твоём распоряжении имелась ZFS, то про ext2/ext3 ты бы забыл как про страшный сон.

> А знаешь, почему у тебя их несколько?

Потому, что я могу выбрать ФС под задачу, в отличие от тебя выбирающего только между убогой UFS и монстрообразной ZFS :-)

> Если бы в твоём распоряжении имелась ZFS, то про ext2/ext3 ты бы забыл как про страшный сон.

90% тех фич, которые превозносятся в ZFS, у меня в линуксе давно есть, причем в промышленной эксплуатации :-)

> причем в промышленной эксплуатации :-)

так в солярке она тоже давно в промышленной. Это во фре казуалы боятся ее использовать, а все нормальные люди, у кого прямые руки, потихоньку на нее переходят. Часть серверов проекта freebsd.org на уже довольно давно на zfs поживает.

> потихоньку на нее переходят

исключая embeded и уж очень дохленькие i386, но на таких и объемов больших не бывает

>Потому, что я могу выбрать ФС под задачу, в отличие от тебя выбирающего только между убогой UFS и монстрообразной ZFS :-)

Убогая UFS в Solaris и OpenSolaris. Во FreeBSD давно уже современная UFS2+SU. ;) Так что вопрос о выборе FS действительно актуален только в (Open)Solaris и Linux.

>и монстрообразной ZFS

Это как так? Какие у вас основания считать ZFS монстрообразной?

Для создания пула массивов ZFS нужно набрать в консоли две строчки и восемнадцать секунд времени на разметку. Для создания пула массивов Ext3FS нужно набрать девять строк и ждать тридцать минут времени на форматирование томов.
http://www.sun.com/software/whitepapers/solaris10/zfs_linux.pdf (стр.7)

> 90% тех фич, которые превозносятся в ZFS, у меня в линуксе давно есть

в разработке да, тот же tux3 очень интересен. Если верить википедии, то не так много на линухе фс поддерживающих проверку целостности считываемых данных. lvm если и найдет несовпадающую checksum'у, то фиг укажет какой файл стоит заменить при отсутствии репликаций.

> Во FreeBSD давно уже современная UFS2+SU. ;)

и крашится она так же современно. Не напоминайте об этом хаке под названием softupdates.

> Какие у вас основания считать ZFS монстрообразной?

да хотя бы из-за своего аллокатора памяти, который постоянно уводит фрю на kmem_map too small. Даже zfs_20080727.patch.bz2 до конца не решает проблемы черезчур прожорливости этой ФС.

> проблемы черезчур прожорливости этой ФС.

На одиночном винте больше свисты в целом?

>> Во FreeBSD давно уже современная UFS2+SU. ;)
> и крашится она так же современно.

Расскажите, очень интересно. Я ни разу не видел упавшую UFS2.

> Не напоминайте об этом хаке под названием softupdates.
Да, в Ext3FS до него не додумались, а вместо него заюзали журнал, отрывающий под себя 20% ёмкости диска и время CPU на верифицируемый I/O. Про Ext2FS ничего не говорю — это усовершенствованная FAT32, но без возможности восстановления. Ж)

>> Какие у вас основания считать ZFS монстрообразной?
> да хотя бы из-за своего аллокатора памяти, который постоянно уводит фрю на kmem_map too small. Даже zfs_20080727.patch.bz2 до конца не решает проблемы черезчур прожорливости этой ФС.

С самого начала было чётко ясно, что ZFS работает на устройствах с ОЗУ >1ГБ.

> > > Есть lvm с реализованным copy-on-write, снапшотами, возможностью организации raid и реализованными в raid-5 контрольными суммами и восстановлением ошибок (в случаях когда это теоретически возможно).

> > Это не относится к ФС

>А это и не должно относиться к уровню ФС. Управление хранением - функция LVM.

Да? И когда я грохну часть файлов, у меня LVM осводит место, выделенное при copy-on-write? Ой-ли?

Ещё раз, прочитай мой самый первый вопрос про ФС. Я спорсил про ФС. И попросил (специально) не говорить ни о чём, кроме как про ФС. Я даже привёл примиры того, что меня не интересует.

Я хотел узнать про ФС. И до сих пор хочу. Так понятнее?

>Да? И когда я грохну часть файлов, у меня LVM осводит место, выделенное при copy-on-write? Ой-ли?

вы себе технологию четко представляете или нет?

> вы себе технологию четко представляете или нет?

А вы всегда отвечаете вопросом на вопрос?

>Это не относится к ФС. Я специально несколько раз упомянул в вопросе ФС. И попросил не советовать костыли. Конечно, lvm поддерживает copy-on-write. Только это совсем не то, что подразумевается в ФС (так как lvm понятия не имеет ни о каких файлах).

я что-то связи между copy-on-write и файлами вообще никакой не вижу: если блок _меняется_ он копируется на снапшот, куда вставить слово файл?

Из чего у нас файлы состоят? Что "освобождается" (помечается, как сводобные) при удалении файла(ов)?

>copy-on-write
> Я хотел узнать про ФС. И до сих пор хочу

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

>Из чего у нас файлы состоят? Что "освобождается" (помечается, как сводобные) при удалении файла(ов)?

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

Будет изменён один блок с этим файлом. Если есть ссылки на этот же блок - то будет изменена его копия.

А вы вообще про какую ФС?

А давайте сначала разберемся с copy-on-write? Снапшоты пока я не трогаю.

Вы, случаем, не еврей? Ходят слухи, что они имеют привычку отвечать вопросами на вопрос. Если судить по этому признаку - то вы один из них ж)

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

>А давайте сначала разберемся с copy-on-write? Снапшоты пока я не трогаю.

с ней нечего разбираться, технология уже достаточно старая и в ней уже все давно отлажено, и в AIX и в Linux работает абсолютно одинаково, даже EMC работает с блоками а не с файлами, только вот Вы похоже начитались маркетингового булшита от Sun и пытаетесь убедить всех в какой-то новизне.

>Я это к тому, что снапшоты могут делаться ночью, а основная загрузка - днём, когда приходят юзеры и активно работают (например, строят код/етц). И в этом случае никаких снапшотов нет.

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

> >А давайте сначала разберемся с copy-on-write? Снапшоты пока я не трогаю.

> с ней нечего разбираться, технология уже достаточно старая и в ней уже все давно отлажено, и в AIX и в Linux работает абсолютно одинаково, даже EMC работает с блоками а не с файлами, только вот Вы похоже начитались маркетингового булшита от Sun и пытаетесь убедить всех в какой-то новизне.

Я всего лишь спросил названия ФС. Не больше. И если вам так уж хочется поделиться знаниями, то просто ответили бы одним предложением и всё. А так - всё время пытаетесь выставить всех идиотами и кретинами. Ну, каждый пытается самоутвердиться как может. Жалко, что заместо простого обмена информацией и помощью "обчитавшимся маркетингового бреда" инивидуумам вы строите из себя не понятно кого, заместо простых ответов на конкретные вопросы.

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

> ещё не находится ни в одном из снапшотов.

>Я всего лишь спросил названия ФС

еще раз: ФС к снапшотам не имеет никакого отношения, на снапшоте такая же ФС как и на LV, с которой сделан снапшот, обращение к блокам LV через спаншот абсолютно прозрачно.

>И если вам так уж хочется поделиться знаниями, то просто ответили бы одним предложением и всё. А так - всё время пытаетесь выставить всех идиотами и кретинами.

вы идиот и кретин, а я не еврей.

> вы идиот и кретин, а я не еврей.

Да-да, все вокруг п%дорасы, одни вы тут д'Артаньян на белом коне. В обще-то, это была шутка (там специально стоял смайлик). И написал я это после энного раза, как вы ответили вопросом на вопрос. Так что уж извините.

> еще раз: ФС к снапшотам не имеет никакого отношения

It depends. Посмотрите в сторону plan9 и его механизма снапшотов (снапшоты доступны только по чтению).

А так как вы пытаетесь обсуждать непонятно какую ФС и непонятно какой Logic Volume (linux LVM2 or whatever?) то извините, я сегодня что-то плохо мысли читаю на расстоянии. С давлением сегодня что-то не то..

И не могли бы вы всё ж таки перечислить ФС с поддержкой copy-on-write (и, если получится, с остальными плюшками)?

>Посмотрите в сторону plan9 и его механизма снапшотов

все кому не лень используют plan9 в продакшене, только я чет торможу.

>А так как вы пытаетесь обсуждать непонятно какую ФС и непонятно какой Logic Volume (linux LVM2 or whatever?)

любой спапшоты в LVM были и остались в LVM2, если хотите, могу поговорить про HPUX и AIX

>И не могли бы вы всё ж таки перечислить ФС с поддержкой copy-on-write

в FS copy-on-write не нужен (и вообще copy-on-write - технология для бедных, split mirror выглядит куда более привлекательнее), потому что такая поддержка несет дополнительный оверхед, впнолне достаточно, что все происходит на уровне блоков.

>если получится, с остальными плюшками

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

> не нужно позиционировать zfs как что-то инновационное

А, вы подумали, что раз я задал этот вопрос в теме про ZFS и раз я перечислил основные "достоинтсва", то это автоматически делает меня "агентом от Сан", который "превозносит" ZFS? Да мне, вобщем-то, как пофиг на неё. Я хотел просто посмотреть подобные ФС (и до сих пор хочу увидеть список)

Хорошо, пусть будет вместо copy-on-write split-mirror. Можно увидеть краткий список ФС с основными возможностями? На педивикии вменяемого сравнения не нашёл. К сожалению. Вот и задал вопрос.

И по-возможности без фраз типа "copy-on-write не нужен" и т.д. На мой взгляд это лишний бесполезный шум. Если есть что-то за место CoW - то так и можно написать. А эти лоровские "бла-бла не нужен, закапывайте обратно/етц" - "в топку" ж)

> Потому, что я могу выбрать ФС под задачу, в отличие от тебя

Ну да, конечно, выбор между говном и ещё большим говном дорогого стоит.

> выбирающего только между убогой UFS и монстрообразной ZFS :-)

Чушь про "монстрообразность" могут нести только те, для кого "зелен виноград".

>> Если бы в твоём распоряжении имелась ZFS, то про ext2/ext3 ты бы забыл как про страшный сон.

> 90% тех фич, которые превозносятся в ZFS, у меня в линуксе давно есть, причем в промышленной эксплуатации :-)

Надо же, как замечательно. Так ты расскажи об этом разработчикам ядра, а то они зачем-то кинулись писать btrfs, а ведь всё есть уже, да ещё и в промышленной эксплуатации.

Ты либо нагло врёшь, либо не разбираешься в предмете. Ни одна из линуксовых ФС ни с LVM, ни без, всей функциональностью ZFS не обладает.

>А это и не должно относиться к уровню ФС. Управление хранением - функция LVM.

Der Junge ist ein-wenig zurückgeblieben :)

>Ты либо нагло врёшь, либо не разбираешься в предмете. Ни одна из линуксовых ФС ни с LVM, ни без, всей функциональностью ZFS не обладает.

Не , он не врёт :) А brtfs кинулись писать, потому-что не могут линковаться с не GPL кодом. В данном случае GPL сыграл с линуксом злую шутку. Прошу учесть, что именно ГПЛ не позволяет, а не CDDL. Которая кстати OSI-approved: http://www.opensolaris.org/os/licensing/opensolaris_license/

Именно поэтому, ZFS можно использовать в BSD и MacOS и даже в Вынь портировать можно попробовать. А в Linuх никак.

Повторяю для ... тех кто непонял !!! GPL тормозит прогресс ! Использование Sun-ом, очень грамотное решение. У линукс коммьюнити не получилось схалявить в этот раз, как это вышло с BSD-лицензированым кодом. GPL не свободная, а очень хищническая лицензия - она в отличае от BSD и CDDL требует весь совместный код лицензировать под собой. Это прямое ограничение свободы, и никакой фанатизм столлманистов меня не убедит, что GPL свободная лицензия.

опять в дурке перебои с лекарствами.

> Расскажите, очень интересно. Я ни разу не видел упавшую UFS2.

iZEN, я уже говорил Вам, придётся повторить: Ваша убеждённость вызывает уважение, но сказок рассказывать не нужно. UFS2 кладётся до невосстановимого состояния несколькими последовательными выключениями во время активного использования дисков, или просто в момент fsck после предыдущего сбоя. Я до сих пор помню срач на bsdportal.ru, когда меня закидывали говном всем форумом за то, что я усомнился в надёжности UFS. А чуть позже на форуме какой-то персонаж робко пытался получить помощь после того, как потерял 200GB архив с музыкой. AFAIR, не получил.

Это касается также и нескольких других распространённых мифов для BSD-неофитов, которые Вы любите периодически цитировать. Не надо их мусолить; одни из них уже устарели, другие же были сильно притянуты за уши или просто лживы с самого начала. Пропаганда Pavlovsky-style всегда вредила этой, в общем-то отличной, системе.

P.S. Если что, я сам - вполне довольный пользователь FreeBSD.

> lvm если и найдет несовпадающую checksum'у, то фиг укажет какой файл стоит заменить при отсутствии репликаций.

lvm не отвечает за файлы. lvm отвечает за устройства, вообще-то...

> Я спорсил про ФС

А я сказал, что в ФС эти функции не нужны.

> А я сказал, что в ФС эти функции не нужны.

Я бы поспорил. Мне, например, очень нравится возможность указать для заданного каталога необходимость сохранения трёх копий каждого блока, принадлежащего любому файлу из этого каталога. Причём zfs будет стремиться раскидать блоки по разным устройствам, а если пул состоит из одного устройства - по максимально отдалённым друг от друга областям устройства. Таким образом у меня организовано хранение каталога текущих проектов - шансы откачать информацию в случае появления бэдов существенно увеличиваются.

Или вот хранение документации или исходников - задал сжатие каталога - и каталог занимает на диске в три раза меньше места.

И то, и другое работает на уровне файловой системы, оперируя положением файлов, а не блоков.

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

>lvm если и найдет несовпадающую checksum'у, то фиг укажет какой файл стоит заменить при отсутствии репликаций

LVM вернет ошибку драйверу ФС, ФС ядру, ядро приложению. Результат как в zfs, только проще в реализации, а значит надежнее.

> LVM вернет ошибку драйверу ФС, ФС ядру, ядро приложению. Результат как в zfs, только проще в реализации, а значит надежнее.

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

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

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

Я конечно, поддерживаю ZFS вообщем и в FreeBSD в частности,
но вот не надо так передергивать !

То что ext3 не умеет отложенную разметку делать - это как бы все знают.
На том же железе под UFS2 будет те же 30 мин форматироваться, а вот под XFS будет быстро форматироваться.

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

Никто не говорит что они будут сложнее, просто их будет сложнее разрабатывать и тестировать. По-отдельности проще, это независимые части и могут работать разные люди. Без блокировок для синхронизации :)

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

Стандартизация рулит, любой lvm подходит к любой fs, любая карта pci подходит к любому контроллеру pci...

Кроме того, разработчики и так в одной команде. Вход свободный, присылайте патчи.

>Пример с файлами, которые система разбрасывает по разным носителям, чтобы максимально обезопасить...

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

> LVM вернет ошибку драйверу ФС, ФС ядру, ядро приложению. Результат как в zfs, только проще в реализации, а значит надежнее.

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

>Вот я после нескольких раз повторения одного и того же вопроса до сих пор жду ответа. И это мне пришлось несколько раз повторять простой вопрос! ж)

Антон? Уральский, ты?!

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

Отличная фича. У меня на ноутбуке 1 (один) винт. Зеркала не организовать. Из-за специфики работы резервное копирование может выполняться и каждый день (норма), и раз в две недели. Каждый день в рабочем каталоге меняется куча файлов. И зная, что каждый файл лежит на диске в трёх копиях, я ощущаю себя несколько спокойней, поскольку покрытие бэдами от сильного удара какой-то области диска с гораздо меньшей вероятностью мне что-нибудь порушит. Понятно, что винт убить можно и насовсем - но, в любом случае, вероятность выцарапать данные гораздо выше.

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

Нет, не я.

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

> Причём zfs будет стремиться раскидать блоки по разным устройствам

А когда в ZFS навернутся метаданные, ты вспомнишь добрым словом независимые разделы и rsync по крону, но конечно тут мы этого не услышим :-)

> шансы откачать информацию в случае появления бэдов существенно увеличиваются

... при регулярном выполнении бэкапов, да.

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

Потому, что дублирующиеся сущности. Каждая из подстистем в отдельности дааавно уже вылизана, и баги лезут только в весьма экстравагантных случаях. А в ZFS был повторно изобретен велосипед, путем дублирующей реализации всего, что уже сделано в LVM, blkdev, VFS и собственно драйверах файловых систем.

> единой командой должна наоборот, дать лучший результат.

_Незначительно_ лучший результат. В настоящий момент живущие в линуксовом ядре "стабильные" ФС дают производительность, сравнимую со скоростью работы физического накопителя, и для 99.99% случаев их эффективность достаточна. А "фичи"... Ну да, звучит все это как минимум интересно. Тем не менее достичь тех же целей с большей результативностью можно существующими средствами.

Пример с "хранением данных в нескольки копиях" мы уже рассмотрели, прозрачно сжатие? Ну НЕ НУЖНО оно. Нынче бытовой накопитель имеет объем 500 гигабайт и стоит $100. Даже не смешно.

> Отличная фича. У меня на ноутбуке 1 (один) винт. Зеркала не организовать

Есть LVM, есть разделы, есть rsync. Они уже работают, и они дадут ЗАМЕТНО БОЛЬШУЮ надежность.

> А когда в ZFS навернутся метаданные, ты вспомнишь добрым словом независимые разделы и rsync по крону, но конечно тут мы этого не услышим :-)

уже тысячу раз говорили, zfs не отменяет необходимости backup'а. checksum'ы и копии помогают от незаметных глюках железа

а метаданные могут пропасть глюкануть и у logical volume manager'а; знаем, проходили

> ... при регулярном выполнении бэкапов, да.

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

> есть rsync

ога, очень эффективно на больших объемах :rofl:

> Они уже работают, и они дадут ЗАМЕТНО БОЛЬШУЮ надежность.

zfs тоже *уже* работает и *уже* дает заметно большую надежность на сановских серверах и начинает награждать фряшников и (скоро?) нетников

btw, до zfs во фре использовали geom, что есть более гибкий аналог линуксявого lvm, а до geom был vinum, ccd и куча костылей...

> Потому, что дублирующиеся сущности. Каждая из подстистем в отдельности дааавно уже вылизана, и баги лезут только в весьма экстравагантных случаях. А в ZFS был повторно изобретен велосипед, путем дублирующей реализации всего, что уже сделано в LVM, blkdev, VFS и собственно драйверах файловых систем.

вылизанные костыли дороже правильной реализации. К тому же во фре нет никакого дублирования функциональности lvm, бо используется функционал geom

> В настоящий момент живущие в линуксовом ядре "стабильные" ФС дают производительность, сравнимую со скоростью работы физического накопителя

Ложь.

> для 99.99% случаев их эффективность достаточна

Отучаемся говорить за всех.

> А "фичи"... Ну да, звучит все это как минимум интересно. Тем не менее достичь тех же целей с большей результативностью можно существующими средствами.

Расскажите, как реализовать все (подчёркиваю: ВСЕ) возможности ZFS в Линуксе. С тестами, доказывающими сравнимый уровень производительности и надёжности. С примерами использования в существующих датацентрах и системай уровня предприятия.

>сжатие? Ну НЕ НУЖНО оно. Нынче бытовой накопитель имеет объем 500 гигабайт и стоит $100. Даже не смешно.

Зелен виноград.

> checksum'ы и резервные копии дают шанс найти (и исправить).

Ну и сразу потерять все, в случая краха метаданных ФС. Все - это и разбивку стораджа под тома, и данные...

> А когда в ZFS навернутся метаданные, ты вспомнишь добрым словом независимые разделы и rsync по крону, но конечно тут мы этого не услышим :-)

Ну, вроде как и это разработчики учли. :) Метаданные резервируются тоже. Причём, и тут интеграция системы играет положительную роль - фс, зная об устройстве физического уровня, резервирует метаданные оптимально по скорости и надёжности.

> Тем не менее достичь тех же целей с большей результативностью можно существующими средствами.

Голословное утверждение. Перестанет быть таковым, если Вы приведёте пример того, как организовать наиболее вкусные особенности zfs средствами lvm/ext3/etc.

> Пример с "хранением данных в нескольки копиях" мы уже рассмотрели, прозрачно сжатие? Ну НЕ НУЖНО оно. Нынче бытовой накопитель имеет объем 500 гигабайт и стоит $100. Даже не смешно.

Ну... У меня исходники занимают около 25ГБ, и разного рода документация - около 50. Винт на ноуте - 250. На данный момент сжатие для исходников - 3.26, для документов - 1.89. Экономия навскидку около 40ГБ. А мне ещё, каюсь - грешен, хочется на винте коллекцию музыки держать, фильмов несколько для минут досуга. Для работы - десяток распакованных виртуалок с имиджами дисков в 2-16ГБ, и ещё десяток запакованных... Так что экономия 16% винта для меня весьма существенна.

А вообще - безапелляционность утверждений до добра не доводит. Не надо говорить за весь мир.

>> Тем не менее достичь тех же целей с большей результативностью можно существующими средствами.

> Голословное утверждение. Перестанет быть таковым, если Вы приведёте пример того, как организовать наиболее вкусные особенности zfs средствами lvm/ext3/etc.

Что ты считаешь вкусными средствами zfs? Транзакционность, ради поддержки которой каждую программу надо переписать (сами санки ради этого отдельный nfs-сервер для работы с zfs писали)? Снапшоты, которые без транзакционности (см. пункт 1) ничем не лучше обычного tar?

> Что ты считаешь вкусными средствами zfs? Транзакционность, ради поддержки которой каждую программу надо переписать (сами санки ради этого отдельный nfs-сервер для работы с zfs писали)? Снапшоты, которые без транзакционности (см. пункт 1) ничем не лучше обычного tar?

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

Re^2: Вышел ZFS-FUSE 0.5.0

>> Что ты считаешь вкусными средствами zfs? Транзакционность, ради поддержки которой каждую программу надо переписать (сами санки ради этого отдельный nfs-сервер для работы с zfs писали)? Снапшоты, которые без транзакционности (см. пункт 1) ничем не лучше обычного tar?

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

А я чо, против транзакционности? Просто для пользования ею программы надо переписывать.

>А я чо, против транзакционности? Просто для пользования ею программы надо переписывать.

Уточните, какие программы надо переписывать.

> Транзакционность, ради поддержки которой каждую программу надо переписать (сами санки ради этого отдельный nfs-сервер для работы с zfs писали)?

Не надо ничего переписывать. У zfs есть механизмы совместимости с posix, и любая posix-программа нормально работает, ничего о транзакциях не зная.

>> А я чо, против транзакционности? Просто для пользования ею программы надо переписывать.

> Уточните, какие программы надо переписывать.

Ну сами санки уже переписали nfs-сервер _специально_ для работы с zfs.

>> Транзакционность, ради поддержки которой каждую программу надо переписать (сами санки ради этого отдельный nfs-сервер для работы с zfs писали)?

> Не надо ничего переписывать. У zfs есть механизмы совместимости с posix, и любая posix-программа нормально работает, ничего о транзакциях не зная.

Есть. Но работает через пень-колоду. Напомни, там на какой сисколл вызывается коммит транзакции: только на close или еще и на flush? Или вообще на каждый write?

> Есть. Но работает через пень-колоду.

Откуда информация? Есть опыт копания в исходниках, или длительного тестирования? Или это просто предположение?

> Напомни, там на какой сисколл вызывается коммит транзакции: только на close или еще и на flush? Или вообще на каждый write?

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

"В ZFS предусмотрен эффективный механизм поддержки приложений, нуждающихся в гарантии того, что данные записаны на диск. Он называется ZFS Intent Log или ZIL и гарантирует сохранение данных на диске, не теряя преимуществ отложенного сохранения изменений в рамках групп транзакций. Вскоре этот механизм планируется усовершенствовать так, чтобы он позволил использовать для хранения ZIL отдельные быстродействующие устройства, например отдельные быстрые или твердотельные диски, а это даст существенный выигрыш в производительности."

Мой личный опыт использования zfs указывает на то, что скорость работы с диском "нетранзакционных" программ вполне укладывается в определение "шустро". При этом ни разу за всё время использования zfs (C FreeBSD 7.0 beta 2) при пропаданиях питания или паниках данные не были порушены. А проверка диска (scrub) ни разу не показала ошибок.

>А когда в ZFS навернутся метаданные, ты вспомнишь добрым словом независимые разделы и rsync по крону, но конечно тут мы этого не услышим :-)

Девушка, у вас вроде 5 звездей в рейтинге, а в голове к сожалению мякина. Обосновываю: RTFM !

Re^2: Вышел ZFS-FUSE 0.5.0

>> Есть. Но работает через пень-колоду.

> Откуда информация? Есть опыт копания в исходниках, или длительного тестирования? Или это просто предположение?

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

>> Напомни, там на какой сисколл вызывается коммит транзакции: только на close или еще и на flush? Или вообще на каждый write?

> Не напомню, поскольку не знаю. Я так далеко не залазил. Вот цитата из "брошюрки для чайников", подтверждающая, что об этом разработчики тоже подумали. Полагаю, при необходимости информацию о тонкостях функционирования найти несложно.

Помимо брошюрок для файников надо иметь и свой критически настроенный ум.

> "В ZFS предусмотрен эффективный механизм поддержки приложений, нуждающихся в гарантии того, что данные записаны на диск. Он называется ZFS Intent Log или ZIL и гарантирует сохранение данных на диске, не теряя преимуществ отложенного сохранения изменений в рамках групп транзакций. Вскоре этот механизм планируется усовершенствовать так, чтобы он позволил использовать для хранения ZIL отдельные быстродействующие устройства, например отдельные быстрые или твердотельные диски, а это даст существенный выигрыш в производительности."

Это всё звучит красиво, но не имеет отношения к обсуждаемому.

> Мой личный опыт использования zfs указывает на то, что скорость работы с диском "нетранзакционных" программ вполне укладывается в определение "шустро". При этом ни разу за всё время использования zfs (C FreeBSD 7.0 beta 2) при пропаданиях питания или паниках данные не были порушены. А проверка диска (scrub) ни разу не показала ошибок.

См контрпример.

> См контрпример.

И что? Таким образом работает любая файловая система. Дополнительная защита метаданных только сохраняет целостность и непротиворечивость файловой системы, но не пользовательских данных. В этом плане zfs предлагает программе, не умеющей работать с транзакциями, ровно тот же результат, что и все остальные системы - после падения целостность данных не гарантируется, если программист не предпринимал специальных усилий для её достижения (т.е. не реализовал транзакции на уровне прикладного софта).

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

Re^4: Вышел ZFS-FUSE 0.5.0

>> См контрпример.

> И что? Таким образом работает любая файловая система. Дополнительная защита метаданных только сохраняет целостность и непротиворечивость файловой системы, но не пользовательских данных. В этом плане zfs предлагает программе, не умеющей работать с транзакциями, ровно тот же результат, что и все остальные системы - после падения целостность данных не гарантируется, если программист не предпринимал специальных усилий для её достижения (т.е. не реализовал транзакции на уровне прикладного софта).

Да.

> Так откуда здесь пень-колода? Обычная обратная совместимость - не умеешь пользоваться новым функционалом - он тебе недоступен, но весь старый - на месте.

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

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

Извини, братан, ты по ходу бредишь. Не пробовал проверять, параллелятся ли ДОСовские задачи под офтопиком? А что, ось же вроде многозадачность поддерживает, и процы с кучей ядер? Чо за херня, почему переписывать-то надо?

И да, раз пошла такая пьянка - приведи пример файловой системы, корректно исполняющей транзакции (и какая версия libastral.so при этом используется) для софта, ничего ей о транзакциях не говорившего.

Re^6: Вышел ZFS-FUSE 0.5.0

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

> Извини, братан, ты по ходу бредишь. Не пробовал проверять, параллелятся ли ДОСовские задачи под офтопиком? А что, ось же вроде многозадачность поддерживает, и процы с кучей ядер? Чо за херня, почему переписывать-то надо?

Что-то не понял намёков.

> И да, раз пошла такая пьянка - приведи пример файловой системы, корректно исполняющей транзакции (и какая версия libastral.so при этом используется) для софта, ничего ей о транзакциях не говорившего.

С чего ты взял, что, даже если такие ФС существуют, мне о них известно?

> С чего ты взял, что, даже если такие ФС существуют, мне о них известно?

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

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

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

Re^8: Вышел ZFS-FUSE 0.5.0

>> С чего ты взял, что, даже если такие ФС существуют, мне о них известно?

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

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

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

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

Там эти три признака были перечислены через логическое "и". А коммерческий суппорт для поделки финского студента предоставляет далеко не одна компания.

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

>> Извини, братан, ты по ходу бредишь. Не пробовал проверять, параллелятся ли ДОСовские задачи под офтопиком? А что, ось же вроде многозадачность поддерживает, и процы с кучей ядер? Чо за херня, почему переписывать-то надо?

> Что-то не понял намёков.

У тебя фимоз головного мозга, потому и не понимаешь ни черта. Разумеется, для использования новой функциональности требуется новый, расширенный API, т.к. новые функции не укладываются в рамки старых моделей. Самое интересное будет тогда, когда новые возможности, реализуемые сейчас Sun'ом станут стандартами (а они обязательно станут) и разработчики линукса сломя голову бросятся доделывать то, что уже годами работает в Solaris.

Re^8: Вышел ZFS-FUSE 0.5.0

> У тебя фимоз головного мозга, потому и не понимаешь ни черта.

И ты не болей.

> Разумеется, для использования новой функциональности требуется новый, расширенный API, т.к. новые функции не укладываются в рамки старых моделей. Самое интересное будет тогда, когда новые возможности, реализуемые сейчас Sun'ом станут стандартами (а они обязательно станут) и разработчики линукса сломя голову бросятся доделывать то, что уже годами работает в Solaris.

То есть всё-таки программы надо переписывать. Что я и сказал ещё вчера.

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

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

Re^10: Вышел ZFS-FUSE 0.5.0

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

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

Да-да, а анонимность должна придать твоим пустым словам больше авторитетности, чудилка? :)

> Да-да, а анонимность должна придать твоим пустым словам больше авторитетности, чудилка? :)

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

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

//Cache

Re^12: Вышел ZFS-FUSE 0.5.0

> Впрочем, речь не о моей анонимности, и не об авторитете, а о том, что ты позволяешь себе однозначно негативные высказывания о продукте, которым не пользовался, а потом еще и заявляешь, что назвал его говном, потому, как он тебе таким увиделся. Отличный, сильно аргументированный ответ.

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

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

> Я им пользовался в достаточной степени, чтобы делать подобные заявления.

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

У меня zfs используется на личном ноутбуке и нескольких серваках разной степени навороченности, везде под FreeBSD. В принципе, я могу утверждать, что знаю основные проблемы этой ФС под FreBSD на данный момент, так же, как и примерный путь её развития. Тот факт, что я не являюсь PC-программистом, и не могу рассуждать о сисколах, полагаю, не мешает мне оценивать ФС в качестве администратора.

На мой взгляд, эта ФС под FreeBSD ещё не достигла стадии продакшн для моих задач (манипулирование большими объёмами данных в интересах домашнего пользователя и мелкого/среднего бизнеса), но активно к ней движется. Прикидочный срок достижения - полгода-год, версия 7.2 FreeBSD. Тогда это будет совершенно ядерная система, после чего UFS останется уделом маргиналов и параноидальных администраторов на загрузочных разделах.

Использование ФС в данный момент указывает на некоторые проблемы с производительностью и стабильностью, я ещё ни разу не привело к потерям данных. В сети так же крайне мало (единицы) отзывов о потерях данных, практически все имеют статус решённых/обойдённых.

> На мой взгляд, эта ФС под FreeBSD ещё не достигла стадии продакшн для моих задач (манипулирование большими объёмами данных в интересах домашнего пользователя и мелкого/среднего бизнеса), но активно к ней движется.

ты пробовал zfs_20080727.patch.bz2 и vfs.zfs.prefetch_disable=1 ? у мя лично 11-ая версия zfs вообще не выпадает в панику ни на каких файлах. 13-ую версию, которая лежит в p4 в //depot/user/pjd/zfs я пока не пробовал, но именно она будет скоро в HEAD.

> Использование ФС в данный момент указывает на некоторые проблемы с производительностью и стабильностью, я ещё ни разу не привело к потерям данных. В сети так же крайне мало (единицы) отзывов о потерях данных, практически все имеют статус решённых/обойдённых.

я два раза чуть не потерял данные из-за глючного контроллера. В обоих случаях zfs-метки были не синхронизованы (это на mirror было) и после банального dd все возвращалось на круги своя. На соляркином форуме была даже дискуссия, что у zfs должна быть утилита, которая восстанавливает битые метаданные, а они могут быть, например, из-за глючной памяти, контроллера (очень редко) и бага в самой фс (таких в 6-ой версии было довольно много).

> В обоих случаях zfs-метки были не синхронизованы (это на mirror было)

нет, естственно zfs меня чуть до инфаркта не довела сообщив metadata corruption и invalid vdev configuration. Странно, что возможность банально переписать метки (zdb -l /dev/ad0, весом 256к каждая) при помощи dd не документирована или я просто не нашел.

> Ну сами санки уже переписали nfs-сервер _специально_ для работы с zfs.

Сильное утверждение, забористая трава видно была :-)

По-моему очевидно, что ни одна файловая система не может знать про то, какое состояние файлов на диске является целостным с точки зрения того или иного приложения. Хотя может я отстал от жизни и просто не в курсе, что такая удивительная ФС уже существует.

Есть довольно много приложений, которые переписывать не надо. В Oracle 'begin backup' зачем существует?

> сами санки ради этого отдельный nfs-сервер для работы с zfs писали

Можете показать здесь - src.opensolaris.org/ переписанный специально для zfs nfs сервер ? Вы же не из "воздуха" это взяли ?

> И нашёл контрпример: программе надо обновить два файла, а момент создания снапшота произошёл после записи первого, но перед записью второго.

не сложно изобразить "контрпример" на практическом примере ? чтобы можно было обсудить ?

Re^4: Вышел ZFS-FUSE 0.5.0

>> И нашёл контрпример: программе надо обновить два файла, а момент создания снапшота произошёл после записи первого, но перед записью второго.

> не сложно изобразить "контрпример" на практическом примере ? чтобы можно было обсудить ?

Легко: программа deluser обновляет аж три файла при своей работе: passwd, shadow и groups. Надо ли говорить, что если забэкапить состояние, когда пользхователь уже удалён из passwd, но ещё находится в shadow и groups, целостность базы пользователей будет нарушена?

Re^2: Вышел ZFS-FUSE 0.5.0

>> сами санки ради этого отдельный nfs-сервер для работы с zfs писали

> Можете показать здесь - src.opensolaris.org/ переписанный специально для zfs nfs сервер ? Вы же не из "воздуха" это взяли ?

Я взял это из того, что для экспорта "обычной" ФС и zfs через nfs надо использовать различные команды и не смешивать их (так и пишут: "не смешивайте" -- http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Using...).

> транзацкионность позволяет избавиться от такого костыля как журнал
гм - Вы вообще представляете себе что оба этих слова значат?
и как именно обычно делется "транзацкионность" ну, например, в Oracle?

> Я взял это из того, что для экспорта "обычной" ФС и zfs через nfs надо использовать различные команды и не смешивать их (так и пишут: "не смешивайте" -- http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Using.. .).

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

Оба способа работают одинаково. Просто если вы делаете это средствами ZFS, информация о том, что файловую систему нужно раздать по NFS, сохраняется в пуле, и если его экспортировать и импортировать на другой машине, файловые системы не только подмонтируются куда нужно автоматически, но и автоматически будут отданы по NFS со всеми нужными параметрами. Если делать это по старинке - с помощью команды share и/или соответствующего конфигурационного файла, - заботиться об этом придется самостоятельно.

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

Вы были бы правы, если бы сказали, что ZFS была интегрирована с реализацией NFS в Solaris, но говорить о том, что NFS-сервер переписан заново - это чересчур. В конце концов, вся история ZFS с момента интеграции в build 27 доступна в Mercurial, так что если не верите на слово - можете взять и посмотреть, насколько велик был объем изменений, связанных с NFS-сервером.

> Легко: программа deluser обновляет аж три файла при своей работе: passwd, shadow и groups. Надо ли говорить, что если забэкапить состояние, когда пользхователь уже удалён из passwd, но ещё находится в shadow и groups, целостность базы пользователей будет нарушена?

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

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

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