Энтузиасты взяли в свои руки реализацию ZFS для MacOS X

>Кстати, дома у меня живут ext3, reiserfs (в основном), xfs (для музыки, фильмов и прочей мультимедии). jfs нет.
Твои проблемы.
И ещё вопрос, нахрена ты с локали на локаль скачешь?

ansi> А ты хотел чтоб как ext2 -> ext3 и обратно?

ZFS - она ZFS и есть. Она на ZFS, ZFS2, ZFS3, а ZFS.

Ставлю систему и ожидаю, чтобы имеющиеся разделы с ZFS были совместимыми с новой системой, и... оказывается, что ZFS такого не умеет.

Конечно. Там 18 дисков в RAID-10 + hotspare.

«Там» это где? На md soft RAID или на аппаратном RAID? Ж))

Честно, мне на десктопе нужна одна функция, допустим есть разделы / и /home и нужно двигать границу между ними в любом направлении, кто это умеет?

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

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

linuxfan> для fat или ntfs

А это тут при чём? Там своя кодировка и ФС не линуксовые.

>Это потому что ты не пробовал fsck запускать на файлухе с 28млн файлов.

При наличии SU на разделе после аварии fsck запускается фоновым процессом и, по моим наблюдениям, занимает от 10 до 30% процессорных ресурсов в зависимости от производительности процессора, продолжительность полной проверки примерно ~20 минут для 300ГБ раздела.
Учи матчасть.

linuxfan> Ответ: никак.

Слив засчитан. Так как я юникодом вовсю пользуюсь.
Жги дальше, ламер. У тебя хорошие способности клоуна.

linuxfan> mkdir -p /tmp/encodings && cd /tmp/encodings && touch "Русский UTF.txt" && LC_ALL=ru_RU.KOI8-R touch "$(echo "Русский KOI8.txt" | iconv -futf-8 -t koi8-r)" && LC_ALL=ru_RU.UTF-8 ls *.txt && LC_ALL=ru_RU.KOI8-R ls

Хм...

linuxfan> Теперь дошло?

То, что ты извращенец и фанатик садо-мазо - дошло.

>Открой лучше тему про FAT или NTFS.

1. su -

1.5. modprobe loop # на всякий пожарный

2. cd /tmp/ && dd if=/dev/zero of=fs.vfat bs=1k count=1024 && losetup /dev/loop2 fs.vfat && mkfs.vfat /dev/loop2 && mkdir -p fat && mount -o codepage=866,iocharset=koi8-r /dev/loop2 fat && touch "fat/$(echo "Русский KOI8.txt" | iconv -futf-8 -tkoi8-r)" && umount fat && mount -o codepage=866,iocharset=utf8 /dev/loop2 fat && touch "fat/Русский UTF.txt" && ls fat && umount fat && losetup -d /dev/loop2

Feel the difference

>> А ты хотел чтоб как ext2 -> ext3 и обратно?

>ZFS - она ZFS и есть. Она на ZFS, ZFS2, ZFS3, а ZFS.

Простенько то как. T.e если бы она звалась ZFSv6, ZFSv13, то одним поводом покидаться какашками было бы меньше?

frey> Честно, мне на десктопе нужна одна функция, допустим есть разделы / и /home и нужно двигать границу между ними в любом направлении, кто это умеет?

Parted вроде бы.

> При наличии SU

нету этих индивидуальных SU в датацентре. В среднем раз в год питалово падает.

> fsck запускается фоновым процессом и, по моим наблюдениям, занимает от 10 до 30% процессорных ресурсов

И при этом 100% винта и вообще на тачке хрен что сделаешь в этот момент. Кстати, вот этот баг исправлен? http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031721.html

И что будет если fsck захочет исправить файл в который идёт запись или к которому идёт обращение?

> Учи матчасть.

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

ansi> Простенько то как. T.e если бы она звалась ZFSv6, ZFSv13, то одним поводом покидаться какашками было бы меньше?

Было бы хотя бы видно, что есть что. А тут - ничего непонятно. Ну и отсутствие обратной совместимости - это скорее минус, чем плюс. Ext3 тем и была хороша, что отлично утилиты от Ext2 с ней работали. Ну а уж Ext4... тут пришлось саму ФС перерабатывать. Но зато получилось ощутимое преимущество. А в случае с ZFS?

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

Btrfs, вон, даже вообще не учитывает порядок байтов, а всё туда же — красно-чёрные деревья, ёмныть.

Так что ФС Btrfs непереносима между архитектурами x86&amd64 и arm&mips&sparc.
(Перетыкаешь флещку с линакса на арму и видишь, что байтики-таки перепутались :))

>Не далее как на прошлой неделе проводили раскидывание используемого логического юнита по полкам в дисковом массиве. И таки надо было уменьшить файловую систему до размера нового LU, а потом собрать это все вместе и нарастить обратно.

Использовали снимки файловой системы? Команды dump/restore с ключиком "-L" для UFS2? :))

>И ещё вопрос, нахрена ты с локали на локаль скачешь?

Я преданный последователь *.KOI8-R, а вот продажные utf-ные "лайнаксоиды" скакали с KOI на UTF и жрали кактус, и писали скрипты.

А все почему? Все потому что в нормальных фс имя файла -- это последовательность символов, а в наколенных поделках -- последовательность байт. Кстати, именно по этой причине UTF-16 имена не могут жить на ext3 (нулевые байты в символах латиницы).

Как бы, если ты поставил у себя ru_RU.UTF-8 и думаешь, что теперь "ниибаццо юникодный пацан", у меня для тебя плохие новости: ты всего лишь определил порядок сортировки символов, формат вывода чисел (все здравомыслящие люди, кстати, себе прописывают LC_NUMERIC=POSIX или C) и способ для преобразования символов с устройств-терминалов при работе с текстовой консолью.

Нормальные люди могут пользовать такой "юникод" хоть с ISO8859-1. Единственной проблемой будет перемещение по строкам и удаление символов длиннее 1 байта, но это мелочи.

iZEN> (Перетыкаешь флещку с линакса на арму

Тяжёлый случай. Флэшка с такой ФС, да ещё и считать арм операционной системой... Срочно к психиатору!

>Ну а уж Ext4... тут пришлось саму ФС перерабатывать. Но зато получилось ощутимое преимущество.

Ext4 писали по мотивам UFS2, вообще-то.

>Parted вроде бы.

Ага, щазз. Хрен он тебе двинет границу на примонтированном /

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

iZEN> Ext4 писали по мотивам UFS2, вообще-то.

Ссылочку давай. А то ты частенько лжёшь.

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

Ну откуда такие идиоты как ты берутся?.. Chroot не знают, устройство ФС не знают, и начинают всякую чушь гнать.

Ссылочку давай. А то ты частенько лжёшь.

А ты хорошенько присмотрись к свойства обеих ФС и удивись как много совпадений. ;-)

> Еще раз для тех кто в танке - пользоваться снапшотами в LVM НЕВОЗМОЖНО.

Еще раз для упертых - снапшоты в LVM работают вполне себе комфортно, и performance penalty действует только на ПЕРВУЮ запись в блок. И то, только при условии проблем с кэшем.

[root@viking dalth]# lvscan | grep md
ACTIVE '/dev/serenity/mdx1' [1,00 GB] inherit
[root@viking dalth]# dd if=/dev/zero of=/dev/serenity/mdx1 bs=4M
1073741824 bytes (1,1 GB) copied, 18,5648 s, 57,8 MB/s
[root@viking dalth]# lvcreate -s -n mdx2 -L 1032M /dev/serenity/mdx1
Logical volume "mdx2" created
[root@viking dalth]# dd if=/dev/zero of=/dev/serenity/mdx1 bs=4M
1073741824 bytes (1,1 GB) copied, 96,0413 s, 11,2 MB/s
[root@viking dalth]# dd if=/dev/zero of=/dev/serenity/mdx1 bs=4M
1073741824 bytes (1,1 GB) copied, 18,751 s, 57,3 MB/s
[root@viking dalth]# dd if=/dev/zero of=/dev/serenity/mdx1 bs=4M
1073741824 bytes (1,1 GB) copied, 18,6946 s, 57,4 MB/s

Все ожидаемо и потери на _первой_ записи, и нулевые потери на всех последующих. Это на одном диске, без RAID, без кэша.

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

Да, снимки задействовали, потому как все проводилось на живую. UFS в прошлом, мы полгода назад перевели последний сервер на zfs.

> А ты хорошенько присмотрись к свойства обеих ФС и удивись как много совпадений. ;-)

А это ничего, что кодовая база ext4 на 90% состоит из кодовой базы ext3, вплоть до того, что при определенных условиях они совместимы и драйвер одной может монтировать другую? :-)

И к чему это ?

>cd /tmp/ && dd if=/dev/zero of=fs.vfat bs=1k count=1024 && losetup /dev/loop2 fs.vfat && mkfs.vfat /dev/loop2 && mkdir -p fat && mount -o codepage=866,iocharset=koi8-r /dev/loop2 fat && touch "fat/$(echo "Русский KOI8.txt" | iconv -futf-8 -tkoi8-r)" && umount fat && mount -o codepage=866,iocharset=utf8 /dev/loop2 fat && touch "fat/Русский UTF.txt" && ls fat && umount fat && losetup -d /dev/loop2

Это должно продемонстрировать то, что и так всем известно ?

Если тебя в детстве привалило кодовой страницей с кои-8, это не значит, что всем так досталось.

Можешь взять в качестве образца содержимое fs/jfs/jfs_unicode.c и fs/jfs/jfs_unicode.h и добавить подобный функционал в extX. Тебе ведь без этого функционала никак, да ?

>..тут пришлось саму ФС перерабатывать. Но зато получилось ощутимое преимущество. А в случае с ZFS?

Ок, будем считать это её недостатком.

>Chroot не знают, устройство ФС не знают, и начинают всякую чушь гнать.

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

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

Во-вторых, устройства ФС не знаешь ты, раз гордо заявляешь "у меня юникод".

Юникод в линаксе не дотягивает до уроня Win95, а юникода в линаксовом ядре нет в принципе. Для ядра даже строк нет, есть "последовательности байт, завершающихся нулем" -- и все. Вся локаль в юзерспейсе, но прыщавая школота пишет locale, видит "UTF-8" и гордо идет 3.14здеть на лоре о том, о чем вообще ни малейшего представления не имеет.

>А это ничего, что кодовая база ext4 на 90% состоит из кодовой базы ext3

А я не говорил, что копировали код. Я сказал "по мотивам". Что Мойша напел. Ж))

>> Изобрази мне RAID-10 (4 диска) на LVM тремя командами

>pvcreate /dev/cciss/c0d0p1
>vgcreate VolGroupXYZ /dev/cciss/c0d0p1
>Уложился в две команды :-)

Кстати, жду пояснения насчёт этого самого "тама" в виде /dev/cciss/c0d0p1.

А пока Ежи шаманил, Петруччо добавил в ZFS еще и поддержку исключения дубликатов файлов. На уровне драйвера файловой системы.

http://www.opennet.ru/opennews/art.shtml?num=24092 http://blogs.sun.com/bonwick/en_US/entry/zfs_dedup

И как же мне, используя другие файловые системы, соорудить это же с такой же скоростью?

>Можешь взять в качестве образца содержимое fs/jfs/jfs_unicode.c и fs/jfs/jfs_unicode.h и добавить подобный функционал в extX.

Нет, не могу. Потому что это повлечет за собой бинарную несовместимость форматов этих ФС и придется либо придумывать костыли вроде длинных имен в vfat, либо забыть об обратной совместимости.

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

Ну, удачи ребятам.
Правда мне пока ни мак, ни ZFS не грозят.
# / на reiser, да.

> Это есть даже в убогом FAT'е, но не в великих линуксовых фс, которые клали на интернационализацию с прибором.

ШИТО????
Это новая реинкарнация Анатолия что ли?
Может Вы уже завяжете с веществами, в конце-концов!

> Еще раз для тех кто в танке - пользоваться снапшотами в LVM НЕВОЗМОЖНО.

ну все, договорились - дальше некуда)))))

>Еще раз для упертых - снапшоты в LVM работают вполне себе комфортно, и performance penalty действует только на ПЕРВУЮ запись в блок. И то, только при условии проблем с кэшем.

А мужики-то не знали. Ты это сам придумал или высмотрел где-то?:)

>Все ожидаемо и потери на _первой_ записи, и нулевые потери на всех последующих. Это на одном диске, без RAID, без кэша.

Ты не указывешь размер данных при записи, в курсе что при записи данных, превышающих размера снапшота, он молча отваливается?:)

># / на reiser, да.

Рейзер есть гавно. ZFS уникальная файловая система.

>Рейзер есть гавно.

Можешь предложить что-то лучше для линакса?

btrfs

Линуксвентилятор увидел русские буковки в Win95 и решил, что это юникод. :)

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

>P.S.
>Бросай косяк.

тссс! не спугни этого троля. после череды вантузо-тупиц, появилось хоть что-то с мозгом. может это даже ирси вылез.

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

А что мешает прикрутить в драйвер fs преобразование кодировки на лету при монтировании ext*? Типа mount -o iconv,fscs=koi8-r,iocharset=utf8 -t ext2 /dev/oldlinuxvolume /mnt/tmp ?

А-ку-еть! Сижу я вечером в солярке на ноуте, потягиваю спиртное, разгребаю be со снэпшотами и наблюдаю как срутся линуксоиды между собой по поводу zfs под MacOS. Мир сошёл с ума, однако)

Ну, кроме того, что это не нужно, потому что есть convmv. Думаю, было бы не хуже nls и codepage для фат и нтфс.

> А что мешает прикрутить в драйвер fs преобразование кодировки на лету при монтировании ext*?

То, что это ненужно. Сколько раз за последние три года ты менял локаль? :-)

> отсутствие поддержки юникода в пингвинячьих фс.

Драйвер ФС интерпретирует имя файла как цепочку байт, и ломать эту фичу, заложенную в POSIX, это верх идиотизма. В действительности, функция взаимоотношения приложений и ФС это задача libc.

int open(char * filename, int mode) {
char * unicode_name = iconv(currentencoding(),"UTF-8");
return sys_open(unicode_name,mode);
}

> 255 _characters_

А теперь вопрос на засыпку - чем 256 отличается от 128? И то, и другое конечные числа одного порядка.

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