Представлен (https://groups.google.com/a/zfsonlinux.org/forum/?fromgroups...) релиз ZFSonLinux 0.6.2 (http://zfsonlinux.org/), реализации файловой системы ZFS, оформленной в виде модуля для ядра Linux. Наработки проекта основаны на оригинальном коде ZFS, импортированном из проекта OpenSolaris и расширенном улучшениями и исправлениями от сообщества Illumos. Реализованная в ZFSonLinux версия пула и файловой системы совместима с ZFS из состава Illumos и FreeBSD. Проект развивается под руководством Брайана Белендорфа (создатель http-сервера Apache) при участии сотрудников Ливерморской национальной лаборатории по контракту с Министерством энергетики США.
В рамках ZFSonLinux подготовлена стабильная и полнофункциональная реализация поддержки компонентов ZFS, связанных как с работой файловой системы, так и с функционированием менеджера томов. В частности, реализованы компоненты: SPA (Storage Pool Allocator), DMU (Data Management Unit), ZVOL (ZFS Emulated Volume) и ZPL (ZFS POSIX Layer). Дополнительно проектом обеспечена возможность использования ZFS в качестве бэкенда для кластерной файловой системы Lustre.
Готовые установочные пакеты подготовлены (http://zfsonlinux.org/) для большинства дистрибутивов Linux, включая Debian, Ubuntu, Fedora, RHEL/CentOS. Кроме того, модуль ZFSonLinux уже входит в состав дистрибутивов Gentoo и Sabayon Linux. Код распространяется под свободной лицензией CDDL, которая несовместима с GPLv2, что не позволяет добиться интеграции ZFSonLinux в состав основной ветки ядра Linux, так как смешивание кода под лицензиями GPLv2 и CDDL недопустимо. Для обхода данной лицензионной несовместимости было решено распространять продукт целиком под лицензией CDDL в виде отдельно загружаемого модуля, который поставляется отдельно от ядра.В новой версии:
- Обеспечена совместимость с ядром Linux 3.11;
- В поставку включен скрипт arcstat.py, созданный изначально проектом FreeNAS;
- Реализована команда 'zpool labelclear', портированная из FreeBSD;
- Из Illumos перенесена возможность сжатия с использованием алгоритма L2ARC и поддержка нити I/O deadman;
- В вызовы lseek()/llseek() добавлена поддержка опций SEEK_DATA/SEEK_HOLE;
- Для модуля ядра добавлена доступная на запись опция arc+l2arc;
- Улучшено определение расширенного формата дисков;
- Улучшена производительность чтения в конфигурациях множественного зеркалирования;
- В zdb обеспечено отображение расширенных атрибутов (SA xattrs).URL: https://groups.google.com/a/zfsonlinux.org/forum/?fromgroups...
Новость: http://www.opennet.me/opennews/art.shtml?num=37742
Эх не в состав бы его, а при установке выбирать можно было бы, тогда бы я забыл про все другие фс.
dkms и initramfs с успехом позволяют забыть про другие фс.
>dkms
>фс
Ичто? Или пользуцтесь уде скомпилированными модулями.
>...тогда бы я забыл про все другие фс.Windows-way? No way!!!
Нахрена использовать для всего один инструмент? Это у MS только две FS, да и те с большими недочётами.
В GNU/Linux можно для разных задач подбирать подходящие инструменты. Их много.
А "универсальная FS" всегда будет глючить.
> А "универсальная FS" всегда будет глючить.Расхожее заблуждение.
Чем больше программный продукт используется, чем больше находятся новые области его использования (use case), чем больше пользователей с различными интересами его используют, тем стабильнее и предсказуемее получается продукт, быстрее совершенствуются его самые нужные свойства и достигаются требуемые показатели качества. Так случилось с NTFS, Ext* и ZFS, используемыми в промышленных масштабах, а другие ФС почему-то заняли свою довольно узкую нишу "местечковых" и/или специализированных ФС.
Во бред то.
Чем больше находятся новые области его использования (use case), тем больше у него этих самых нужных свойств. Для универсальных (панацей) ВСЕ его свойства нужные. Иначе нехрен претендовать на универсальность вообще.
Уже сейчас ни одна минимальная(!!!) инсталяция линуха не обходится только extX, там есть devfs, sysfs, tmpfs, shmfs, procfs и тд. Можно было обойтись без них? Да. А нужно? Нет.
И это не говоря про более слож6ые конфигурации, про кластерные и шаред фс.
> Во бред то.
> Чем больше находятся новые области его использования (use case), тем больше у
> него этих самых нужных свойств. Для универсальных (панацей) ВСЕ его свойства
> нужные. Иначе нехрен претендовать на универсальность вообще.
> Уже сейчас ни одна минимальная(!!!) инсталяция линуха не обходится только extX, там
> есть devfs, sysfs, tmpfs, shmfs, procfs и тд. Можно было обойтись
> без них? Да. А нужно? Нет.
> И это не говоря про более слож6ые конфигурации, про кластерные и шаред
> фс.Все перечисленные fs (кроме ext) - это, вообще-то, виртуальные файловые системы/рам-диски. Требовать от ZFS чтобы она показывала какие устройства в системе есть или какие процессы запущены - это как-то странно немного...
>Все перечисленные fs (кроме ext) - это, вообще-то, виртуальные файловые системы/рам-диски.Что не делает из них НЕ файловые системы.
Можно обойтись без devfs, tmpfs,… для этих же целей средствами другой фс (ext4/zfs/…)?
Можно.
Так что претензии не принимаются.>Требовать от ZFS чтобы она показывала какие устройства
Вот именно.
Об этом как раз и речь. Каждой задаче своё решение.
зыж
Пример применения как кластерной, шаред фс вы осознано проигнорировали?
zfs share давно уже есть (samba и nfs) - этого достаточно? Для кластера - да, проблематично. Но есть AVS (под соляркой, под другими системами - не в курсе), да и можно банально снапшоты гонять периодически.
samba поддерживет (с 3.6.0) smb2 протокол и CTDB - что позволяет создать кластер на самбе (up 6 или 8 нод)..
Изя, ты в последнее время вырос в моих глазах как минимум на полметра. Всё правильно говоришь!
Плюсанул в карму.
> Это у MS только две FS, да и те с большими недочётами.Недочеты в студию, а то будем считать балаболом
Помолчи, тролль-подросток.
Все это уже 100500 раз тут было, в том числе и такие набросы.
Так что сходи к папе или там аризу и спроси совета, как надо троллить современными методами. А то этот не канает.
http://lmgtfy.com/?q=ntfs+disadvantages
>> Это у MS только две FS, да и те с большими недочётами.
> Недочеты в студию, а то будем считать балаболомФрагментация ?
> Недочеты в студию, а то будем считать балаболомТормозная ФС с архаичным дизайном из 90-х годов прошлого века. Просто в целом прошлый век ФСостроения. Как паровозы - в целом ничем таким вроде не плохи сами по себе, просто появились дизайны которые лучше, потому юзеж паровозов сошел на нет.
До MS это доползло - оно ReFS кой-как накорябали для серверов, поняв что при наличии ZFS и btrfs если у них не будет чего-то сравнимого - их вообще всерьез воспринимать перестанут. Но десктопных хомяков опять прокатили. Впрочем и на серверах - оно весьма урезанное по фичам относительно упомянутых. Но лучше чем совсем нифига.
Не торопитесь говорить гоп. Вот одна из историй "успеха":
>Сервер мы собрали, Нексенту поставили. Поставили нам ее официальные партнеры Нексенты, сертифицированные инженеры.
>первый косяк мы словили уже через неделю — по мере миграции на Нексенте кончилась память для таблицы дедупликации. … на каждый блок ФС в пуле Нексенте надо примерно 500 байт в памяти для таблицы дедупликации. Если у нас в системе 128Гб памяти, Нексента может хранить инфу про 256 000 000 блоков: максимальный размер занятого пула на 4К блоках — 1Тб, на 16К блоках — 4Тб, на 32К блоках — 8Тб и на 64К блоках — 16Тб. Запишите это красным маркером на стене! Зайдете за границу и прощай премия =)
>Если не так задали размер блока в самом начале — ничто не поможет, кроме миграции на новый том с правильным размером.
>Еще про дедупликацию на блочном уровне. Это не работает, забудьте.
>Тут всплывает второй косяк, не описанный в маркетинговых материалах сразу. Стоит ZFS пулу заполниться, как он радикально деградирует по производительности. Более 30% свободного места это не бросается в глаза (но видно на графике), с 30 до 10% все работает раза в три медленнее, а если места становится менее 10% — все работает на порядок медленнее.http://habrahabr.ru/company/hostkey/blog/179151/
и это на нексенте. вот на линухе http://habrahabr.ru/post/153461/
>если места становится менее 10% — все работает на порядок медленнееТочно ZFS тестировали, а не NTFS?
Линк вроде дал, прочитай.
>>если места становится менее 10% — все работает на порядок медленнее
> Точно ZFS тестировали, а не NTFS?Точно точно, у NTFS 50% ;)
> Точно точно, у NTFS 50% ;)Тебе, как бсдшнику с putty.exe виднее :).
> Не торопитесь говорить гоп. Вот одна из историй "успеха":
>>Сервер мы собрали, Нексенту поставили. Поставили нам ее официальные партнеры Нексенты, сертифицированные инженеры.
>>первый косяк мы словили уже через неделю — по мере миграции на Нексенте кончилась память для таблицы дедупликации. … на каждый блок ФС в пуле Нексенте надо примерно 500 байт в памяти для таблицы дедупликации. Если у нас в системе 128Гб памяти, Нексента может хранить инфу про 256 000 000 блоков: максимальный размер занятого пула на 4К блоках — 1Тб, на 16К блоках — 4Тб, на 32К блоках — 8Тб и на 64К блоках — 16Тб. Запишите это красным маркером на стене! Зайдете за границу и прощай премия =)
>>Если не так задали размер блока в самом начале — ничто не поможет, кроме миграции на новый том с правильным размером.
>>Еще про дедупликацию на блочном уровне. Это не работает, забудьте.
>>Тут всплывает второй косяк, не описанный в маркетинговых материалах сразу. Стоит ZFS пулу заполниться, как он радикально деградирует по производительности. Более 30% свободного места это не бросается в глаза (но видно на графике), с 30 до 10% все работает раза в три медленнее, а если места становится менее 10% — все работает на порядок медленнее.
> http://habrahabr.ru/company/hostkey/blog/179151/
> и это на нексенте. вот на линухе http://habrahabr.ru/post/153461/А башкой поработать вообще - слабо? С какого перепугу система с идеологией CoW должна при таком заполнении сохранять производительность? И - насколько это лютый недостаток в условиях МАССОВОГО производства терабайтных винтов?
>А башкой поработать вообще - слабо? С какого перепугу система с идеологией CoW должнаНу вот подумай. И не пихай (совместно с айзеном) zfs как универсальную ФС на все случаи жизни.
зыж
Не, как маркетенговый ход орали, что она идеальна для ssd? Орали.
А то что половину этого добра либо не использовать придётся, либо смириться с тормозами — так теперь сами головой думайте. Типа сами дураки. А в чём дураки то? Что вас же послушали.ззыж
>И - насколько это лютый недостаток в условиях МАССОВОГО производства терабайтных винтов?Настолько, насколько ты не замечаешь что тебе пишут. И в каком месте все эти "фичи" фс прострелять тебе ягодицу.
А пишут тебе — a) ssd, б) максимальный размер занятого пула на 4К блоках — 1Тб, на 16К блоках — 4Тб, на 32К блоках — 8Тб и на 64К блоках — 16Тб.
А как фичи эти поотключаешь, то сразу и поймшь, что таже xfs была бы ОЧЕНЬ (и даже лучше) не плоха в этих же условиях.
>то сразу и поймшь, что таже xfs была бы ОЧЕНЬ (и даже лучше) не плоха в этих же условиях.xfs вообще прекрасна. особенно, на свежих ядрах.
zfs, конечно, интересна своими фишками, но у неё весьма специфические требования(как по памяти, так и по свободному месту пула). ну и ряд нерешенных вопросов(например, отсутствие дефрагментатора).
> xfs вообще прекрасна. особенно, на свежих ядрах.Она уже преодолела ограничения в 16ТБ для одного тома? Если да, то с каким успехом?
>> xfs вообще прекрасна. особенно, на свежих ядрах.
> Она уже преодолела ограничения в 16ТБ для одного тома? Если да, то
> с каким успехом?У неё не было такой проблемы.
So how does XFS scale now?
● 8p, 4GB RAM KVM VM.
● Host has 17TB 12 disk RAID0 device, XFS filesystem, 17TB preallocated image file, virtio, Direct IO.
● Guest filesystem uses mkfs, mount defaults except for inode64,logbsize=262144 for XFS.
● Intent is to test default configurations for scaling artifacts.
● Parallel fs_mark workload to create 25 million files per thread.число тредов - от 1 до 8.
Test limited to under 16TB because ext4 doesn't support file sizes more than 16TB!читать: http://xfs.org/images/d/d1/Xfs-scalability-lca2012.pdf
смотреть и просвещаться: http://www.youtube.com/watch?v=FegjLbCnoBwPS: iZEN, а сколько с zfs будет удаляться 2Тб данных в виде 1млн файлов?
(при условии использования striped raidz)
http://share.auditory.ru/2011/Denis.Ovchinnikov/fs.txtXFS
Особенности:
- 64-битная файловая система
- Журналирование только метаданных
- Изменение размера «на лету» (только увеличение)
- Размещение в нескольких разных линейных областях — т. н. «allocation groups» (увеличивает производительность путём - выравнивания активности запросов к разным дискам на RAID-массивах типа «stripe»)
- Дефрагментация «на лету»
- API ввода/вывода реального времени (для приложений жёсткого или мягкого реального времени, например, для работы с - потоковым видео)
- Запись на диск производится только при нехватке памяти. Это позволяет уменьшить фрагментацию, а также снизить - активность запросов к диску.
- Интерфейс (DMAPI) для поддержки иерархического управления хранением (HSM (англ.) )
- Инструменты резервного копирования и восстановления (xfsdump and xfsrestore)
- Реальный размер файла на файловой системе, в отличие от кратного размеру блока.
- Очень большое количество «индексных блоков» inode.Недостатки:
- Невозможно уменьшить размер существующей файловой системы.
- Старые версии XFS страдали от опасности беспорядочной записи, которые могли привести к возникновению таких проблем как — файлы приложений во время краха/ошибки/аварии ФС или приложения набирали хвост из мусора к следующему монтированию ФС.
- Версии загрузчика GRUB до 0.91 не поддерживают XFS.
- Восстановление удалённых файлов в XFS практически невозможно.
- Возможность потери данных во время записи при сбое питания, так как большое количество буферов хранится в памяти.
Относительно высокая нагрузка на центральный процессор
- Вплоть до последних версий на 32-разрядных системах индексные блоки могут размещаться только в начальных 2-Терабайтах на диске. Поэтому, если вдруг при создании файла на XFS-диске с размером более 2 Терабайта выдается ошибка «невозможно создать файл» — попробуйте удалить какой-либо файл, который размещается на диске в начальных 2-Терабайтах, чтобы освободить место для новых индексных блоков.В общем, в сравнении с ZFS — никакая.
> В общем, в сравнении с ZFS — никакая.что именно в приведённом вами тексте позволило сделать такой вывод?
>> В общем, в сравнении с ZFS — никакая.
> что именно в приведённом вами тексте позволило сделать такой вывод?Отсутствие надёжности записи данных в XFS при некорректном завершении работы ФС (сбое питания). Выключат рубильник, а потом нужно запускать xfs.fsck, чтобы обнаружить неконсистентную вермишель.
И ещё это: "Относительно высокая нагрузка на центральный процессор". ZFS никогда не была требовательна к вычислительным ресурсам CPU.
>>> В общем, в сравнении с ZFS — никакая.
>> что именно в приведённом вами тексте позволило сделать такой вывод?
> Отсутствие надёжности записи данных в XFS при некорректном завершении работы ФС (сбое
> питания). Выключат рубильник, а потом нужно запускать xfs.fsck, чтобы обнаружить неконсистентную
> вермишель.онолитег iZEN как всегда в своем репертуаре:
NAME
fsck.xfs - do nothing, successfully
> И ещё это: "Относительно высокая нагрузка на центральный процессор". ZFS никогда не
> была требовательна к вычислительным ресурсам CPU.zfs - самая прожорливая. кстати, что там с O_DIRECT?
> онолитег iZEN как всегда в своем репертуаре:Здравствуйте Онотоле
http://www.linux.org.ru/news/linux-general/9506828/page5?las...///---
Рояль в кустах.Сейчас сын ковырял зачем-то старый ПК на Athlon X2 4200+, nForce MCP61, 4Gb RAM, SuSe. Достали с полки три списанных ST31000340NS.
# modprobe raid5
# mdadm --create /dev/md0 --level=5 --raid-devices=3 --assume-clean /dev/sd[bcd]1
… всякая дичь с pvcreate, vgcreate, lvcreate, mkfs
… наконец …
$ dbench -D . 20
dbench version 4.00 - Copyright Andrew Tridgell 1999-2004Running for 600 seconds with load '/usr/share/dbench/client.txt' and minimum warmup 120 secs
20 of 20 processes prepared for launch 0 sec
…
Throughput 20.4609 MB/sec 20 clients 20 procs max_latency=3094.496 msПривели всё в исходное
# zpool create -o ashift=12 tank raidz sdb1 sdc1 sdd1
# zfs create -o mountpoint=/tmp/test tank/test
… и наконец …
$ dbench -D . 20
dbench version 4.00 - Copyright Andrew Tridgell 1999-2004Running for 600 seconds with load '/usr/share/dbench/client.txt' and minimum warmup 120 secs
20 of 20 processes prepared for launch 0 sec
…
Throughput 104.309 MB/sec 20 clients 20 procs max_latency=2779.481 msКак-то так. Ребенок в восторге обнимается с кошкой.
---///> сколько с zfs будет удаляться 2Тб данных в виде 1млн файлов?
Не могу предсказать, учитывая асинхронность выполнения команды zfs destroy и асинхронность обновления метаданных ZFS в пуле.
зевая...zfs:
Operation Count AvgLat MaxLat
----------------------------------------
NTCreateX 2176030 0.017 912.074
Close 1598255 0.011 911.178
Rename 92153 0.065 599.898
Unlink 439589 0.055 639.005
Deltree 40 41.913 687.975
Mkdir 20 0.003 0.005
Qpathinfo 1972631 0.008 782.705
Qfileinfo 345155 0.001 0.035
Qfsinfo 361675 0.002 1.503
Sfileinfo 177297 0.119 782.377
Find 762493 0.022 1.371
WriteX 1082162 0.054 912.056
ReadX 3410902 0.006 2.310
LockX 7084 0.002 0.015
UnlockX 7084 0.001 0.012
Flush 152548 77.107 643.909Throughput 113.605 MB/sec 20 clients 20 procs max_latency=912.077 ms
xfs:
Operation Count AvgLat MaxLat
----------------------------------------
NTCreateX 3432757 0.030 543.507
Close 2521501 0.002 1526.792
Rename 145389 0.012 2.687
Unlink 693180 0.034 3605.219
Deltree 80 91.839 2662.757
Mkdir 40 0.002 0.003
Qpathinfo 3111451 0.003 1054.382
Qfileinfo 545117 0.001 0.930
Qfsinfo 570516 0.001 1.595
Sfileinfo 279686 0.004 1.509
Find 1202904 0.007 2.587
WriteX 1710303 0.010 3.093
ReadX 5381704 0.002 2.285
LockX 11182 0.002 0.492
UnlockX 11182 0.001 0.029
Flush 240634 49.010 24825.861Throughput 179.387 MB/sec 20 clients 20 procs max_latency=24825.865 ms
>Не могу предсказать, учитывая асинхронность выполнения команды zfs destroy и асинхронность обновления метаданных ZFS в пуле.
нет-нет, какой zfs destroy. давай честный unlink!
> нет-нет, какой zfs destroy. давай честный unlink!Так всё же видно в тесте (исправляю).
zfs:
Operation Count AvgLat MaxLat
----------------------------------------
Unlink 439589 0.055 639.005xfs:
Operation Count AvgLat MaxLat
----------------------------------------
Unlink 693180 0.034 3605.219ZFS чуть медленнее расправляется с файлами, чем XFS, в 1,61 раза (0.055 ms/0.034 ms).
> ZFS чуть медленнее расправляется с файлами, чем XFS, в 1,61 раза (0.055
> ms/0.034 ms).рукалицо.jpg
iZEN, ты слово latency вообще понимаешь?
ну и кроме unlink там еще будет directory lookup.
насчёт цифр по bandwidth будут комментарии о супер-быстрой zfs?
там же еще по vmstat у zfs sys time больше.
>> ZFS чуть медленнее расправляется с файлами, чем XFS, в 1,61 раза (0.055
>> ms/0.034 ms).
> iZEN, ты слово latency вообще понимаешь?Как "задержка". "AvgLat" — "средняя задержка", соотвественно.
> ну и кроме unlink там еще будет directory lookup.
И что?
> насчёт цифр по bandwidth будут комментарии о супер-быстрой zfs?
Отключи ZIL и checksum и будет ZFS такая же быстрая и "надёжная" на запись, как XFS, а может даже быстрее и реактивнее.
> там же еще по vmstat у zfs sys time больше.
Просто так ничего не бывает.
> Отключи ZIL и checksum и будет ZFS такая же быстрая и "надёжная"
> на запись, как XFS, а может даже быстрее и реактивнее.Только потом убьется в хламину и починить нечем будет - а где у нее fsck вообще? Кроме того, CoW сам по себе в принципе достаточно быстрая техника которая может показывать во многих случаях скорость как у обычной ФС с журналом только метаданных, обеспечивая полное журналирование. Что собственно и является одним из аргументов "за" такой дизайн. А тут слив в полтора раза...
>> Отключи ZIL и checksum и будет ZFS такая же быстрая и "надёжная"
>> на запись, как XFS, а может даже быстрее и реактивнее.
> Только потом убьется в хламинуТак XFS тоже убьётся в хламину, если рубильник дёрнуть. А ты недёргай.
> и починить нечем будет - а где у нее fsck вообще?
ZFS не нуждается в fsck, так как при обычном использовании ZIL не допускает неатомарных записей групп транзакций. То есть в случае аварийного завершения работы при последующем монтировании ФС пула происходит автоматический откат группы транзакций примерно на 5 секунд раньше неудавшейся записи. Данные остаются в непротиворечивом состоянии. Если всё же обнаружено несоотвествие контрольных сумм, то в дело вступает scrub, который производит "очистку" пула от неконсистентных данных и выводит полный поимённый список безвозвратно повреждённых и потерянных (для пула) файлов. По этому списку файлы можно восстановить из бэкапа, если требуется. Классический fsck не предоставляет такой возможности, как scrub, и сваливает найденные "остатки" файлов под незначащими именами в каталог /.lost+found — разбирайте по содержимому, что где и откуда.
> Кроме того, CoW сам по себе в принципе достаточно быстрая техника которая может показывать во многих случаях скорость
> как у обычной ФС с журналом только метаданных, обеспечивая полное журналирование.
> Что собственно и является одним из аргументов "за" такой дизайн. А
> тут слив в полтора раза...Так называемый "слив" в полтора раза с дизайном софтверного RAID, который может конфигурироваться без остановки работы, как бы не очень серьёзный фэйл. А вот крах XFS из-за отключения питания и последующая длительная проверка fsck тома, допустим, в несколько терабайт, заставляет задуматься о смысле классических ФС на томах большого объёма.
> Так XFS тоже убьётся в хламину, если рубильник дёрнуть.Может. Но там хотя-бы утилиты для починки есть.
> А ты недёргай.
А ты русский язык не прогуливай. Не с глаголами пишется раздельно.
>> и починить нечем будет - а где у нее fsck вообще?
> ZFS не нуждается в fsck, так как при обычном использовании ZIL не
> допускает неатомарных записей групп транзакций.ZFS "не нуждается" в fsck, потому что сани решили что полный fsck для такой монстряки получается как-то слишком сложно, поэтому гораздо интереснее, проще и дешевле просто скормить лохам маркетингового булшита. По той же причине он "не нуждается" в дефрагере и что там еще. Как оно фрагментится - ты же нам и показал с 6М/сек на шпиндель. Как оно не нуждается в fsck - показал другой деятель на лисяре, устраивавший закат солнца вручную.
> То есть в случае аварийного завершения работы при последующем монтировании ФС пула
> происходит автоматический откат группы транзакцийИли не происходит, если вср@лась какая-то ошибка, например бэд сектор вылез. О том что делать в таком случае саночные пиарасты тактично умалчивают. Ибо общего решения на случай когда случился факап у них нет. Ну как у того кекса на лисяре. Конкретно тот факап таки научили чинить утилитку (которая типа не должна требоваться и поэтому не понятно зачем встроили фичу, если твоей логикой оперировать).
> под незначащими именами в каталог /.lost+found — разбирайте по содержимому, что
> где и откуда.Я не спорю что дополнительное чексуммирование может быть неплохой идеей, если то что оно грузит систему не есть проблема в некоей конфиге. К именно этому пункту никаких особых претензий нет.
>> Что собственно и является одним из аргументов "за" такой дизайн. А
>> тут слив в полтора раза...
> Так называемый "слив" в полтора раза с дизайном софтверного RAID, который может
> конфигурироваться без остановки работы, как бы не очень серьёзный фэйл.По логике вещей CoW на записи имеет все шансы вести себя как минимум не хуже чем ФС журналящая только метаданные, даже ближе к ФС совсем без журнала за счет однократной записи в сферическом CoW в вакууме. Но не сливать же в полтора раза?! При том что XFS сколь-нибудь "быстрый" вообще только на больших файлах, если накопителей несколько, так что файл параллельно разлетается на несколько накопителей. На остальном XFS варьируется от "обычного" до "слоупочного" ;). А тут гражданин даже XFS особо не подыгрывал вроде.
> А вот крах XFS из-за отключения питания и последующая длительная проверка fsck
> тома, допустим, в несколько терабайт, заставляет задуматься о смысле классических ФС
> на томах большого объёма.Там нет никакого fsck после отключения питания. Там только обработка журнала и ... все. ФС при этом логически корректна. Но как и у всех ФС с неполным журналингом, файл который перезаписывался в момент факапа может быть в промежуточном состоянии - наполовину старый и наполовину новый. Просто потому что старые данные файла нигде не прихранены, равно как новые данные целиком до начала записи тоже никуда не сохранялись (в классических журналящих ФС это убивает скорость записи в разы, так что не пользуется популярностью).
> Так XFS тоже убьётся в хламину, если рубильник дёрнуть. А ты недёргай.ради интереса сколько раз дергал - не убивалась.
> ZFS не нуждается в fsck, так как при обычном использовании ZIL не
> допускает неатомарных записей групп транзакций. То есть в случае аварийного завершения
> работы при последующем монтировании ФС пула происходит автоматический откат группы транзакций
> примерно на 5 секунд раньше неудавшейся записи.это настраивается, если чо. и тут традиционный баланс между производительностью и сохранностью данных
>Данные остаются в непротиворечивом
> состоянии.Изя, ну что такое "данные в непротиворечивом состоянии"?
приложение пишет на диск 4кб данных. если в этот момент дернуть питание, то нет наких гарантий что после отката данные будут на диске. чудес не бывает.
> Если всё же обнаружено несоотвествие контрольных сумм, то в дело
> вступает scrub, который производит "очистку" пула от неконсистентных данных и выводит
> полный поимённый список безвозвратно повреждённых и потерянных (для пула) файлов. По
> этому списку файлы можно восстановить из бэкапа, если требуется.если мы делаем бэкап, тем более инкрементальный, то немалая часть возможностей zfs нам уже тут же не нужна.
> Так называемый "слив" в полтора раза с дизайном софтверного RAID, который может
> конфигурироваться без остановки работы, как бы не очень серьёзный фэйл.если чо, softraid в linux умеет "changing the RAID level between 1, 5, and 6, changing the chunk size and layout for RAID5", а в этих ваших zfs даже переезд на более объемные диски - это отдельная боль.
> вот крах XFS из-за отключения питания и последующая длительная проверка fsck
> тома, допустим, в несколько терабайт, заставляет задуматься о смысле классических ФС
> на томах большого объёма.читайте доки, они - рулез. нет у xfs долгой проверки. fsck.xfs - это просто заглушка, она ничего не делает.
> приложение пишет на диск 4кб данных. если в этот момент дернуть питание,
> то нет наких гарантий что после отката данные будут на
> диске. чудес не бывает.Месье не в курсе как работает ZFS ? Месье ниасилятор ? Можно даже сказать терминальный ниасилятор ... ;)
ЗЫ Алекс вы сменили ник ? Пришла осень ?
> Месье не в курсе как работает ZFS ? Месье ниасилятор ? Можно
> даже сказать терминальный ниасилятор ... ;)ну расскажите, не томите!
open => write => close (и никаких fsync/fdatasync).
и вот тут где-то пропадает питание.
чтобы вам было проще, представьте, что zfs у нас на lun'е по iscsi, а rtt 60мс.
> ЗЫ Алекс вы сменили ник ? Пришла осень ?вы обознались.
> PS: iZEN, а сколько с zfs будет удаляться 2Тб данных в виде 1млн файлов?У изена с его 6Мб на шпиндель и ноутбучными дисками - чуть менее чем вечность, имхо :)
> У изена с его 6Мб на шпиндель и ноутбучными дисками - чуть менее чем вечность, имхо :)Засунь своё имхо подальше.
Не забывайте добавлять, что речь идет о падении скорости рандомной записи.
Я лучше напомню о чём говорим — «тогда бы я забыл про все другие фс».
Хрен там, не забыл бы.
А если стал пихать zfs без разбору куда попало (наслушавшись айзенов), то ещё бы и из её любителя превратился бы в её ненавистника.
> А если стал пихать zfs без разбору куда попало (наслушавшись айзенов), то ещё бы и из её любителя превратился бы в её ненавистника.Опыт включения дедупликации без предварительной проверки нагрузочной способности новой технологии на боевых серверах впечатляет. :))
Зато вот это: "Стоит ZFS пулу заполниться, как он радикально деградирует по производительности. Более 30% свободного места это не бросается в глаза (но видно на графике), с 30 до 10% все работает раза в три медленнее, а если места становится менее 10% — все работает на порядок медленнее.", — реально доставляет. Ибо на классических ФС место закончится раньше, чем администратор узнает о проблемах нехватки свободного места на томах. ;) В случае ZFS хотя бы есть шанс проконтролировать заполнение пула "доверху" и предпринять какие-то действия в режиме "наблюдения за развитием нежелательной ситуации и постепенной деградации производительности", а не в режиме цейтнота "всё пропало, отключаемся пока не поздно", как в случае классических ФС. ;)
>Ибо на классических ФС место
> закончится раньше, чем администратор узнает о проблемах нехватки свободного места на
> томах. ;)ну т.е. про системы мониторинга не слышали, да?
>В случае ZFS хотя бы есть шанс проконтролировать заполнение
> пула "доверху" и предпринять какие-то действия в режиме "наблюдения за развитием
> нежелательной ситуации и постепенной деградации производительности", а не в режиме цейтнота
> "всё пропало, отключаемся пока не поздно", как в случае классических ФС.
> ;)чего еще проконтролировать? и чем в данной ситуации спасёт zfs?
>Ибо на классических ФС место закончится раньше, чем администратор узнает о проблемах нехватки свободного места на томахс какого бодуна?
>[оверквотинг удален]
> производительности. Более 30% свободного места это не бросается в глаза (но
> видно на графике), с 30 до 10% все работает раза в
> три медленнее, а если места становится менее 10% — все работает
> на порядок медленнее.", — реально доставляет. Ибо на классических ФС место
> закончится раньше, чем администратор узнает о проблемах нехватки свободного места на
> томах. ;) В случае ZFS хотя бы есть шанс проконтролировать заполнение
> пула "доверху" и предпринять какие-то действия в режиме "наблюдения за развитием
> нежелательной ситуации и постепенной деградации производительности", а не в режиме цейтнота
> "всё пропало, отключаемся пока не поздно", как в случае классических ФС.
> ;)Повторяю для тех, кто на бронепоезде.
Идеология CoW при таком заполнении _по-другому работать и не может по определению_. Это раз.
Два - терабайтные винты еще не изобрели?
> Идеология CoW при таком заполнении _по-другому работать и не может по определению_.Да и не-CoW тоже. Потому что вероятность того что в жалких огрызках найдется блок непрерывного размера - стремится к нулю по мере увеличения размера блока. Наступает фрагментец.
>>Сервер мы собрали, ...Совковую лопату мы купили, но суп хлебать ей оказалось совершенно неудобно, даже не смотря на то, что сертифицированный джамшут показывал нам как хлебать борщ со сметаною. Теперь мы ходим каждый день на "Хабр" и плачем там горючими слезами.
1. С дедубликацией эта ситуация стопицоттыщ раз описана. А также в сети существуют довольно подробные разъяснения, как и зачем ей пользоваться.
2. Про деградацию -- а вы Marketing Bullshit больше слушайте. Разработчики про это ещё в 2008 году говорили, и говорили слово в слово то, о чём сказал каментящий выше -- ЛЮБОЙ storage с технологией экспайра по LFU будет тормозить при заполнении стораджа -- что кэш Squid'овый, что ZFS. Это плата за CoW.
И что вы хотите этим сказать?
Что все ваши потуги (в прошлом) — маркетинговый бред?
А народ повёлся, по ссылке бабосы пштратил.
Сами дураки?
Не фсф-вэй такие методы.Зыж
Zfs хороша на файлопомойке. При чём на корпоративной файлопомойке.
Иногда просто лучшая.
Но.
Под субд, виртуалки и тд не катит. Есть решения лучше.
Всегда это говорил, в отличие от фанов (профанов?). Абсолютно невминяемых кстати порой.
> 2. Про деградацию -- а вы Marketing Bullshit больше слушайте. Разработчики про
> это ещё в 2008 году говорили, и говорили слово в слово
> то, о чём сказал каментящий выше -- ЛЮБОЙ storage с технологией
> экспайра по LFU будет тормозить при заполнении стораджа -- что кэш
> Squid'овый, что ZFS. Это плата за CoW.Ну вот личности вроде iZEN рассказывают что ходить по граблям - совершенно приятно и не больно.
Вот что там в ZFS с дефграгментаций(и чем вообще эту фрагментацию можно посмотреть?)
>> 2. Про деградацию -- а вы Marketing Bullshit больше слушайте. Разработчики про
>> это ещё в 2008 году говорили, и говорили слово в слово
>> то, о чём сказал каментящий выше -- ЛЮБОЙ storage с технологией
>> экспайра по LFU будет тормозить при заполнении стораджа -- что кэш
>> Squid'овый, что ZFS. Это плата за CoW.
> Ну вот личности вроде iZEN рассказывают что ходить по граблям - совершенно
> приятно и не больно.
> Вот что там в ZFS с дефграгментаций(и чем вообще эту фрагментацию можно
> посмотреть?)Ничем. В extent-based ФС ее не существует.
>> Вот что там в ZFS с дефграгментаций(и чем вообще эту фрагментацию можно
>> посмотреть?)
> Ничем. В extent-based ФС ее не существует.это, мягко говоря, не так.
> это, мягко говоря, не так.Более жестко говоря, в ZFS к тому же нет нормально реализованных экстентов. Есть блоки переменного размера, но это не то. Впрочем, изен с его 6М на шпиндель как-то раз показал чего примерно можно получить, если загнать CoW в нехватку места :).
>> 2. Про деградацию -- а вы Marketing Bullshit больше слушайте. Разработчики про
>> это ещё в 2008 году говорили, и говорили слово в слово
>> то, о чём сказал каментящий выше -- ЛЮБОЙ storage с технологией
>> экспайра по LFU будет тормозить при заполнении стораджа -- что кэш
>> Squid'овый, что ZFS. Это плата за CoW.
> Ну вот личности вроде iZEN рассказывают что ходить по граблям - совершенно приятно и не больно.А ничего, что я включил дедупликацию на пулах с менее 10% свободного места, протестировал эту фичу на копировании файлов и выложил результаты, на основании которых ты, User294, делаешь далеко идущие выводы о скорости ZFS ВООБЩЕ в 6 МБ/с? Ж)) Оставайся дальше болваном, чего уж там.
> А ничего, что я включил дедупликацию на пулах с менее 10% свободного
> места, протестировал эту фичу на копировании файлов и выложил результаты,Спасибо, чувак. Мне понравилось - настолько @#$вый результат не каждый день увидишь. Чтобы настолько конфигу ушатать - это еще талантище иметь надо :).
> на основании которых ты, User294, делаешь далеко идущие выводы о скорости ZFS
Вообще-то ragus != User294, если уж на то пошло. А то что ему такие результаты тоже доставили - я что, виноват чтоли? При чем тут вообще я?
> ВООБЩЕ в 6 МБ/с? Ж)) Оставайся дальше болваном, чего уж там.Пока-что оболванился тут ты, до кучи перепутав ragus с User294 в своих наездах :). Но спасибо за бесплатное цирковое шоу, мне (294-му) понравилось.
> Вот что там в ZFS с дефграгментаций(и чем вообще эту фрагментацию можно посмотреть?)http://www.linux.org.ru/forum/general/9560485?cid=9563032
///---
В ZFS, если что, нет понятия «фрагмент», есть понятие блок, который может быть разных размеров.Если не менять свойство recordsize, задающее максимальный размер блока, то это будет 128 килобайт. Файлы, размер которых не превышает максимальный размер блока, занимают ровно столько секторов, сколько требуется для их сохранения. При их модификации происходит выделение нового блока, так что файлы размером до максимального размера блока всегда остаются непрерывными. Если файл перерастает максимальный размер блока, то его размер блока фиксируется, и все его блоки в дальнейшем занимают 128 килобайт каждый (при значении recordsize по умолчанию).
В ext4 4 размер блока равен странице, так что при фрагментации файла на блоки размером 4 килобайта эффект от фрагментации может оказаться гораздо печальнее, нежели от фрагментации на блоки размеров 128К.
anonymous (09.09.2013 6:53:46)
---///
По-моему, объяснение годится.
>> Вот что там в ZFS с дефграгментаций(и чем вообще эту фрагментацию можно посмотреть?)А посмотреть то чем можно?
> http://www.linux.org.ru/forum/general/9560485?cid=9563032
Изя, ты самостоятельно думать не умеешь и только копипастишь?
> Если не менять свойство recordsize, задающее максимальный размер блока, то это будет
> 128 килобайт. Файлы, размер которых не превышает максимальный размер блока, занимают
> ровно столько секторов, сколько требуется для их сохранения. При их модификации
> происходит выделение нового блока, так что файлы размером до максимального размера
> блока всегда остаются непрерывными.чудесно. что происходит со старым блоком, после того как данные "переехали" в новый?
hint: metaslab, space map.вся техника борьбы с фрагментацией в zfs описывается вот тут:
When ZFS decides to allocate blocks from a particular metaslab, it first reads that metaslab's space map from disk and replays the allocations and frees into an in-memory AVL tree of free space, sorted by offset. This yields a compact in-memory representation of free space that supports efficient allocation of contiguous space. ZFS also takes this opportunity to condense the space map: if there are many allocation-free pairs that cancel out, ZFS replaces the on-disk space map with the smaller in-memory version.(отсюда взято https://blogs.oracle.com/bonwick/entry/space_maps )
> ---///
> По-моему, объяснение годится.нет не годится. если мы модифицируем большой файл, внутри будут "дырки"(из-за cow).
и ситуация только усугубляется при заполнении пула.
терминальный случай - постоянная перезапись файлов на заполненном пуле.
2 года эксплуатации Nexenta.
2 машинки по 4 "шпинделя".
Не бог весть какая конфигурация, конечно, но работает всё исправно.
И дедупликация отрабатывает (на одном томе коэффициент добежал аж до 5,39x), и компрессия, и снапшоты... Использую то, что мне нужно там, где это будет работать.
Кстати, и iSCSI исправно трудится...
На Linux (Gentoo) тоже уже пару лет как домашняя мультимедия лежит. Тоже без нареканий.
Просто нужно не "панацеи" ждать, а планировать согласно возможностям.
всегда можно доустановить пакеты в уже загруженную для установки ос, разметить из консоли, а потом только выбрать готовое, если установщик сразу не умеет зфс.
всего несколько кликов и команд для живого диска с функцией установки.
Только нужен живой диск и интернет, ии даже просто устаноочный диск.
Про AltLinux опять забыли. А ведь в нем есть ZFSonLinux в отличии от...
До третьего абзаца не дочитал?
как же шигорин смог себя пересилить и использовать вражеские технологии ?!
> как же шигорин смог себя пересилить и использовать вражеские технологии ?!Ну вот так: у некоторых результат приоритетнее, а у некоторых - всякие бзики.
> возможность сжатия с использованием алгоритма L2ARCЭто что за алгоритм такой?
http://wiki.illumos.org/x/foYR
Это не алгоритм сжатия, зеня тут прав. L2arc это кэш 2го уровня. А новость в том, что теперь научились его сжимать. Но новостеписака неправильно перевёл. Явление, для опеннета обычное.
> Это не алгоритм сжатияВ глубине души это LZ4, но его настолько переделали, что он перестал быть LZ4 :)
Павел, ну хоть ты так не тупи
>Background in a nutshell
>The “ARC” is the ZFS main memory cache (in DRAM), which can be accessed with sub microsecond latency. An ARC read miss would normally read from disk, at millisecond latency (especially random reads). The L2ARC sits in-between, extending the main memory cache using fast storage devices – such as flash memory based SSDs (solid state disks).
Developed a new feature that introduces the ability to compress L2ARC contents.
With the inclusion of the very high-performance LZ4 compression algorithm in ZFS,
it is now possible to transparently compress and decompress large volumes of data
with much lower latency and overhead than was previously possible with LZJB. As such,
the L2ARC is the next possible target for transparent compression.
Должно быть написано "возможность сжатия L2ARC с использованием алгоритма LZ4"
> Проект развивается под руководством Брайана Белендорфа (создатель http-сервера Apache)Расхожее заблужение. Спрашивал на LUG у Брайна - он сказал что это просто однофамилец.
>> ZFS не является изначально кластерной, распределенной или параллельной файловой системой и не предоставляет конкурирующего доступа к данным с различных хостов. ZFS — это локальная файловая система.серьезное ограничение, не так ли ?
Если бы файловая система Умела все: "как Путин" она бы занимала в ядре пару гигов озу
> ядре пару гигов озуНе предел мечтания для ZFS, между прочим...
>> ядре пару гигов озу
> Не предел мечтания для ZFS, между прочим...Зависит от того, как настроишь, так-то.
> Зависит от того, как настроишь, так-то.Ну да, выбор между зверскими тормозами и зверским поеданием памяти. Как-то так :).
ну это, если дедупликация включена, без нее разве оно прожорливо?
> ну это, если дедупликация включена, без нее разве оно прожорливо?Оно настраивается _как угодно_, достаточно почесаться посмотреть свойства ФС, помедитировать, и вдумчиво поменять под свои хотелки.
> Если бы файловая система Умела все: "как Путин" ...Браво!
PutinFS - продолжение развития WinFS!!!
Паникует.
bonnie++ -s 61440 -d /zdata -f -b -n 1