Re: ZFS, философское

[Melleus]

Artem Chuprina  writes:

> Как я уже писал, в stretch скриптов для ZFS для sysvinit нет вообще, а юниты
> для systemd, _казалось бы_, написаны правильно, но вот опыт с неудачным
> взлетом (как минимум два раза в процессе установки и настройки конструкции)
> намекает нам, что авотфиг. Какие-то шибко умные подсистемы таки поднимаются в
> параллель, и иногда успевают раньше.

Характерно, что BSD, откуда ZFS происходит, весьма успешно игнорирует
systemd и все потуги по ее продвижению. Что, в общем-то и не
удивительно, исходя из unix legacy BSD и воинствующего игнорирования
принципов unix-way авторами systemd.

Следствием такого состояния вещей логично ожидать отсутствия юнитов,
которые бы предсказуемо взаимодействовали с ZFS. И проблема тут отнюдь
не в ZFS. Точно так же и все проблемы с пульсой решаются лишь
решительным выпиливанием оной. Поэтому в перспективе следует ожидать
лишь лавинообразного увеличения проблем в дистрибутивах, побежденных
адептами systemd, которые отровенно плюют на совместимость,
аргументированную критику и unix-way в целом, ибо не только ZFS пришла
из мира BSD/Unix. Такая вот философия...

Re: ZFS, философское

[Artem Chuprina]

Victor Wagner  writes:

> On Tue, 08 Aug 2017 09:56:42 +0300
> Artem Chuprina  wrote:
>
>> Alex Kicelew  writes:
>
>> > Для меня важно то, что в спуле находятся юзерские кронтабы и
>> > at-jobs.  
>> 
>> Засада... Их как раз нужно восстанавливать. Опять художественное
>> выпиливание...
>
> А у меня в спуле еще mlmmj живет, а там - списки подписчиков списков
> рассылки. 

Эээ... А он разве не в либе?

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

В юниксах традиционно все же разносить разные типы активности одной
подсистемы по разным деревьям. Программы в /usr/bin, библиотеки и
вспомогательные программы в /usr/lib, pid-файлы и сокеты в /var/run,
транзитную почту в /var/spool, а хранимую в /var/mail... Даже в винде с
появлением roaming profiles пошел ощутимый сдвиг в эту сторону.

Но вот с софтом, который ставится в /opt, ситуация противоположная, тут
"все свое ношу с собой". Зато удалять легко. Что как бы намекает нам,
что это с ним и надо делать :)

Re: ZFS, философское

[Victor Wagner]

On Tue, 08 Aug 2017 09:56:42 +0300
Artem Chuprina  wrote:

> Alex Kicelew  writes:

> > Для меня важно то, что в спуле находятся юзерские кронтабы и
> > at-jobs.  
> 
> Засада... Их как раз нужно восстанавливать. Опять художественное
> выпиливание...

А у меня в спуле еще mlmmj живет, а там - списки подписчиков списков
рассылки. 

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

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

Re: ZFS, философское

[Artem Chuprina]

Alex Kicelew  writes:

>> - Выделяет из rpool/var rpool/var/tmp, rpool/var/log, rpool/var/spool,
>>   rpool/var/cache. Последнему отключает автоматические снапшоты, что
>>   логично. Не вполне понятно, забыл он отключить их спулу, или намеренно не
>>   отключил. К спулу в гораздо большей степени, чем к кэшу, относится "это из
>>   бэкапа/снапшота не восстанавливают". Если восстановление кэша хотя бы
>>   безвредно, то спула — вредно. С занудной кочки зрения, снапшоты могут
>>   оказаться полезны для разбирательства, фиг ли письмо доставлено через две
>>   недели, но этого проще превентивно добиться тупо анализом возраста файлов в
>>   спуле. Я у себя спулу автоснапшоты тоже выключил. Для rpool/var/tmp 
>> включает
>
> Для меня важно то, что в спуле находятся юзерские кронтабы и at-jobs.

Засада... Их как раз нужно восстанавливать. Опять художественное выпиливание...

Re: ZFS, философское

[Alex Kicelew]

On 08/07/17 18:16, Artem Chuprina wrote:
> - Выделяет из rpool/var rpool/var/tmp, rpool/var/log, rpool/var/spool,
>   rpool/var/cache. Последнему отключает автоматические снапшоты, что
>   логично. Не вполне понятно, забыл он отключить их спулу, или намеренно не
>   отключил. К спулу в гораздо большей степени, чем к кэшу, относится "это из
>   бэкапа/снапшота не восстанавливают". Если восстановление кэша хотя бы
>   безвредно, то спула — вредно. С занудной кочки зрения, снапшоты могут
>   оказаться полезны для разбирательства, фиг ли письмо доставлено через две
>   недели, но этого проще превентивно добиться тупо анализом возраста файлов в
>   спуле. Я у себя спулу автоснапшоты тоже выключил. Для rpool/var/tmp включает

Для меня важно то, что в спуле находятся юзерские кронтабы и at-jobs.

Re: zfs on linux

[Vasiliy P. Melnik]

Нормально пул импортируется - и без никакого экспорта. Если проблемы с этим
возникают - значит не полностью портировали функционал

13 июля 2017 г., 22:01 пользователь Alex Kicelew 
написал:

> On 07/13/17 12:56, Artem Chuprina wrote:
> > В юзер гайде сказана интересная вещь. Что если не сделать zpool export,
> > то пул потом на другой системе не поднимется. Не то чтобы там было
> > акцентировано на "вообще никак", но и ни про какие --force при импорте
> > тоже не говорилось.
>
> Не удалось навскидку найти пруф, но где-то я совсем недавно читал, что
> без экспорта может (не обязательно, но подчеркивалось, что именно может)
> не получиться перенести пул не на другую, а на ИНУЮ систему -- например,
> с иной тупоконечностью. Хотя не объяснялось, почему эту
> "интернациональную" информацию можно записать только при штатном
> переводе пула в офлайн.
>
>

Re: zfs on linux

[Alex Kicelew]

On 07/13/17 12:56, Artem Chuprina wrote:
> В юзер гайде сказана интересная вещь. Что если не сделать zpool export,
> то пул потом на другой системе не поднимется. Не то чтобы там было
> акцентировано на "вообще никак", но и ни про какие --force при импорте
> тоже не говорилось.

Не удалось навскидку найти пруф, но где-то я совсем недавно читал, что
без экспорта может (не обязательно, но подчеркивалось, что именно может)
не получиться перенести пул не на другую, а на ИНУЮ систему -- например,
с иной тупоконечностью. Хотя не объяснялось, почему эту
"интернациональную" информацию можно записать только при штатном
переводе пула в офлайн.

Re: zfs on linux

[Sergey Matveev]

*** Artem Chuprina  [2017-07-13 12:58]:
>Почитал тут подробно Aaron Toponce's ZFS on Linux User Guide
>(https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux/)

Спасибо за ссылку. Возможно лучшая документация по ZFS для незнакомых с
ним прежде которую я встречал!

>И что, вот прямо реально если, допустим, что-то сдохло и система не
>грузится, то воткнуть диски в другую машину и импортировать пул
>невозможно, привет всем данным, которые там были? Или все-таки -f и -F
>(ман гуглится от FreeBSD, а систему с zfs я еще не поставил) у нас тоже
>есть и работают?

Если pool не был экспортирован, то другая система при импорте
действительно скажет что он "занят", но под FreeBSD force опция без
проблем его импортирует. Я не знаю даже гипотетически к техническим
проблемам каким оно может привести -- я думаю это исключительно чтобы
предупредить человека, на всякий пожарный, мол вдруг он нечаянно что-то
не то хочет сделать, мол явно не сказали export pool, может он нечаянно
хочет и import сделать.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: zfs on linux

[Artem Chuprina]

Artem Chuprina -> debian-russian@lists.debian.org  @ Thu, 13 Jul 2017 12:56:59 
+0300:

 > Что интересно, вышеупомянутый скрипт не делает zpool export. И его
 > README не предлагает этого делать.

Зато делает такое:
# Copy hostid as the target system will otherwise not be able to mount the 
misleadingly foreign file system
cp -va /etc/hostid /target/etc/

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

Re: zfs on linux

[Alex Kicelew]

On 07/10/17 12:04, Dmitry Kulagin wrote:
> Если вы создавали все фс по хелпу, то ваша проблема закономерна,
> в хелпе zpool создается с опцией для файловой системы по умолчанию:
> -O canmount=off, а потом zfs c canmount=noauto. Для вашего случая,
> когда нужны отдельные фс на /usr и /etc, надо (да и в текущих глюках
> systemd для всех) полностью формировать систему (монтировать
> /var /usr /etc и т.д.) еще на этапе initrd поэтому все эти фс да и / тоже
> желательно создавать с опцией canmount=on, и в /etc/default/zfs с опцией
> ZFS_MOUNT='yes'. Отложить монтирование, и как в классике управлять
> /home, /opt, /srv и т.п. с помощью /etc/fstab, можно указав при создании фс
> опцию mountpoint=legacy.

Да, я понимаю. И я уже это исправил, ибо на ноуте мне это не нужно, он
использовался только как полигон. А вот за напоминание про legacy и про
опции /etc/default/zfs спасибо, ибо на другом компе, который я тоже
планирую перевести под zfs, это мне как раз нужно (если, конечно,
удастся поставить там более ранний systemd, который еще не слинкован с
/usr/lib:).

Re: zfs on linux

[Dmitry Kulagin]

Если вы создавали все фс по хелпу, то ваша проблема закономерна,
в хелпе zpool создается с опцией для файловой системы по умолчанию:
-O canmount=off, а потом zfs c canmount=noauto. Для вашего случая,
когда нужны отдельные фс на /usr и /etc, надо (да и в текущих глюках
systemd для всех) полностью формировать систему (монтировать
/var /usr /etc и т.д.) еще на этапе initrd поэтому все эти фс да и / тоже
желательно создавать с опцией canmount=on, и в /etc/default/zfs с опцией
ZFS_MOUNT='yes'. Отложить монтирование, и как в классике управлять
/home, /opt, /srv и т.п. с помощью /etc/fstab, можно указав при создании фс
опцию mountpoint=legacy.

09.07.2017 18:56, Alex Kicelew пишет:

On 07/09/17 18:52, Vasiliy P. Melnik wrote:

Про то, что отдельный /usr постепенно отламывают, даже в информации о
выпуске stretch было упомянуто:

Та при нынешних объемах дисков оно просто бессмысленно. Я вообще делаю бут,
потом все остальное нарезаю лвм-ом, в лвм-е делаю 3 партишина - root и
var_log по 20 гигов, swap на 2 гига. Если под что-то надо место - создаю с
минимальным размером, потом добавляю, если надо. Ресайз на увеличение
работает на лету, на уменьшение - проблемно.

Проблема в том, что на ноуте-то мне это не важно, но я планировал
поставить zfs и на большую машину, где небольшой рейд. Бэкапить zfs,
вроде, удобнее всего снапшотами, но снапшоты делаются на fs. Бэкапить
/etc мне нужно, а вот полный бэкап всего рута вместе с /usr -- нет.

Re: ZFS

[Artem Chuprina]

Sergey Matveev -> debian-russian@lists.debian.org  @ Sun, 9 Jul 2017 22:02:11 
+0300:

 >>Я косым взглядом вижу в описаниях ZFS фичу проверки контрольных сумм и
 >>восстановления при сбоях отдельных блоков. Но вижу ее в контексте RAIDZ,
 >>а его, соответственно, в контексте нескольких дисков. Вопрос. В
 >>контексте одного диска такая фича есть? Надо ли ее как-то специально
 >>включать, или она вообще у ZFS по умолчанию?

 > Важные данные (метаинформация) хранится на ZFS в двух экземплярах, очень
 > важные данные (описания ФС и тому прочее) -- в трёх. Если где-то будет
 > нарушение целостности, то будет смотреться копия. Просто сами данные
 > по-умолчанию хранятся в одном экземпляре и zfs scrub сможет показать что
 > их целостность нарушена, но, естественно, восстановить не сможет. Но
 > если сделать zfs set copies=2 mypool/myfs, то и данные будут в двух
 > экземплярах (можно и 3) и тогда их можно восстановить. Само собой, это
 > потребует в два раза больше места, но восстановить ZFS сможет побитые.

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

Re: ZFS

[Sergey Matveev]

*** Artem Chuprina  [2017-07-09 21:57]:
>Я косым взглядом вижу в описаниях ZFS фичу проверки контрольных сумм и
>восстановления при сбоях отдельных блоков. Но вижу ее в контексте RAIDZ,
>а его, соответственно, в контексте нескольких дисков. Вопрос. В
>контексте одного диска такая фича есть? Надо ли ее как-то специально
>включать, или она вообще у ZFS по умолчанию?

Важные данные (метаинформация) хранится на ZFS в двух экземплярах, очень
важные данные (описания ФС и тому прочее) -- в трёх. Если где-то будет
нарушение целостности, то будет смотреться копия. Просто сами данные
по-умолчанию хранятся в одном экземпляре и zfs scrub сможет показать что
их целостность нарушена, но, естественно, восстановить не сможет. Но
если сделать zfs set copies=2 mypool/myfs, то и данные будут в двух
экземплярах (можно и 3) и тогда их можно восстановить. Само собой, это
потребует в два раза больше места, но восстановить ZFS сможет побитые.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: zfs on linux

[Sergey Matveev]

*** Alex Kicelew  [2017-07-09 19:10]:
>Хм. На большом компе я планировал бэкапить только нужные мне вещи, а вот
>на ноуте думал сделать копию единственного диска и ежедневно сбрасывать
>на нее send-ом наболевшее за день, чтобы при крахе основного винта
>просто с нее сразу же загрузиться, а уже потом докупать еще винт. Вы
>полагаете, что эта идея (под линухом, фри у меня нет) мертворожденная?

Лично я не вижу какое будет отличие GNU/Linux ZFS-а от *BSD-ного. zfs
send/recv же будет работать точно так же. Идея делать инкрементальные
бэкапы (хоть каждый час по cron) мне нравится. Точно так же делал на
ноутбуке где SSD-диску 3.5 года и от него всего можно ожидать.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: zfs on linux

[Vasiliy P. Melnik]

9 июля 2017 г., 19:27 пользователь Alex Kicelew  написал:

> On 07/09/17 19:26, Vasiliy P. Melnik wrote:
> > Я полагаю, что Вы не о том думаете - если Вам так ценен ноут как
> > инструмент, то все же стоит подумать о покупке второго, ибо в ноуте не
> винт
> > самая большая проблема, а перегрев.
>
> Второй у меня есть. Но данные мне тоже важны.


Лично меня полностью устраивает дропбокс - основной документооборот
помещается в бесплатные 2 гига, еще и на телефоне можно посмотреть

Re: zfs on linux

[Alex Kicelew]

On 07/09/17 19:26, Vasiliy P. Melnik wrote:
> Я полагаю, что Вы не о том думаете - если Вам так ценен ноут как
> инструмент, то все же стоит подумать о покупке второго, ибо в ноуте не винт
> самая большая проблема, а перегрев.

Второй у меня есть. Но данные мне тоже важны.

Re: zfs on linux

[Vasiliy P. Melnik]

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


9 июля 2017 г., 19:08 пользователь Alex Kicelew  написал:

> On 07/09/17 19:01, Vasiliy P. Melnik wrote:
> > Я на фре именно снапшотами и бекаплюсь, но это фря.
> >
> > Не надо лезть в в систему, лучше просто рсинком на зфс синхронизируйте, а
> > потом уже делайте снапшот. Все же для линукса это чужая фс, хоть и
> работает
>
> Хм. На большом компе я планировал бэкапить только нужные мне вещи, а вот
> на ноуте думал сделать копию единственного диска и ежедневно сбрасывать
> на нее send-ом наболевшее за день, чтобы при крахе основного винта
> просто с нее сразу же загрузиться, а уже потом докупать еще винт. Вы
> полагаете, что эта идея (под линухом, фри у меня нет) мертворожденная?
>
>

Re: zfs on linux

[Alex Kicelew]

(прошу прощения за копию в личку; не уследил)

Re: zfs on linux

[Alex Kicelew]

On 07/09/17 19:01, Vasiliy P. Melnik wrote:
> Я на фре именно снапшотами и бекаплюсь, но это фря.
> 
> Не надо лезть в в систему, лучше просто рсинком на зфс синхронизируйте, а
> потом уже делайте снапшот. Все же для линукса это чужая фс, хоть и работает

Хм. На большом компе я планировал бэкапить только нужные мне вещи, а вот
на ноуте думал сделать копию единственного диска и ежедневно сбрасывать
на нее send-ом наболевшее за день, чтобы при крахе основного винта
просто с нее сразу же загрузиться, а уже потом докупать еще винт. Вы
полагаете, что эта идея (под линухом, фри у меня нет) мертворожденная?

Re: zfs on linux

[Vasiliy P. Melnik]

Я на фре именно снапшотами и бекаплюсь, но это фря.

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

9 июля 2017 г., 18:56 пользователь Alex Kicelew  написал:

> On 07/09/17 18:52, Vasiliy P. Melnik wrote:
> >> Про то, что отдельный /usr постепенно отламывают, даже в информации о
> >> выпуске stretch было упомянуто:
> > Та при нынешних объемах дисков оно просто бессмысленно. Я вообще делаю
> бут,
> > потом все остальное нарезаю лвм-ом, в лвм-е делаю 3 партишина - root и
> > var_log по 20 гигов, swap на 2 гига. Если под что-то надо место - создаю
> с
> > минимальным размером, потом добавляю, если надо. Ресайз на увеличение
> > работает на лету, на уменьшение - проблемно.
>
> Проблема в том, что на ноуте-то мне это не важно, но я планировал
> поставить zfs и на большую машину, где небольшой рейд. Бэкапить zfs,
> вроде, удобнее всего снапшотами, но снапшоты делаются на fs. Бэкапить
> /etc мне нужно, а вот полный бэкап всего рута вместе с /usr -- нет.
>
>

Re: zfs on linux

[Alex Kicelew]

On 07/09/17 18:52, Vasiliy P. Melnik wrote:
>> Про то, что отдельный /usr постепенно отламывают, даже в информации о
>> выпуске stretch было упомянуто:
> Та при нынешних объемах дисков оно просто бессмысленно. Я вообще делаю бут,
> потом все остальное нарезаю лвм-ом, в лвм-е делаю 3 партишина - root и
> var_log по 20 гигов, swap на 2 гига. Если под что-то надо место - создаю с
> минимальным размером, потом добавляю, если надо. Ресайз на увеличение
> работает на лету, на уменьшение - проблемно.

Проблема в том, что на ноуте-то мне это не важно, но я планировал
поставить zfs и на большую машину, где небольшой рейд. Бэкапить zfs,
вроде, удобнее всего снапшотами, но снапшоты делаются на fs. Бэкапить
/etc мне нужно, а вот полный бэкап всего рута вместе с /usr -- нет.

Re: zfs on linux

[Vasiliy P. Melnik]

>
> Про то, что отдельный /usr постепенно отламывают, даже в информации о
> выпуске stretch было упомянуто:
>

Та при нынешних объемах дисков оно просто бессмысленно. Я вообще делаю бут,
потом все остальное нарезаю лвм-ом, в лвм-е делаю 3 партишина - root и
var_log по 20 гигов, swap на 2 гига. Если под что-то надо место - создаю с
минимальным размером, потом добавляю, если надо. Ресайз на увеличение
работает на лету, на уменьшение - проблемно.

Re: zfs on linux

[Alex Kicelew]

On 07/09/17 18:44, Alexander Galanin wrote:
> This means that for stretch all systems where /usr is a separate
> partition need to use an initramfs generator that will mount /
> usr. All initramfs generators in stretch do so.

У меня сейчас не возможности проверить, do ли они это на стандартных fs,
но вот в zfs точно don't.

Re: zfs on linux

[Alexander Galanin]

09.07.2017 17:07, Alex Kicelew пишет:

Отдельно стоит отметить, что /sbin/init в лице systemd в настоящее время
(версия 233-9) слинкован в числе прочего с одной библиотекой из
/usr/lib. Я не смотрел, до инита монтируются некорневые fs на обычных
системах, или после, но в zfs -- точно после, в результате чего если
/usr расположен на отдельной fs, система при загрузке падает в кернел
паник, ибо невозможно стартовать /sbin/init.


Про то, что отдельный /usr постепенно отламывают, даже в информации о 
выпуске stretch было упомянуто:


5.1.1. Late mounting of /usr is no longer supported

Note

This section only applies to systems using a custom kernel, where
/usr is on a separate mount point from /. If you use the kernel
packages provided by Debian, you are unaffected by this issue.

Mounting of /usr using only tools found in / is no longer
supported. This has only worked for a few specific configurations
in the past, and now they are explicitly unsupported.

This means that for stretch all systems where /usr is a separate
partition need to use an initramfs generator that will mount /
usr. All initramfs generators in stretch do so.

--
Alexander Galanin

Re: zfs on linux

[Alex Kicelew]

On 07/09/17 18:14, Artem Chuprina wrote:
>  > 3) systemd запускается раньше, чем монтируются некорневые fs в составе
>  > zfs, поэтому сервисы, закросслинканные на файлы на некорневых fs при
>  > старте systemd не видны. И если ожидается, что они автостартуют при
...
> После. Точно так же. Так что идея линковать сервисы в некорневую fs
> относится к плохим. Прочесть конфиг, где написано "давай подождем, пока
> вон то смонтируется" надо все же раньше, чем оно смонтируется.

С одной стороны, это логично. Но с другой, в systemd есть system
services, а есть user services. И если первые официально расположены
частично в /etc, частично в /lib, то вторые -- в ~/.config. И то, что у
меня они физически расположены в другой директории в том же ~/, которая
синхронизируется между разными машинами, а в ~/.config/systemd/user
только линки туда, это уже частность.

>  > но в zfs -- точно после, в результате чего если /usr расположен на
>  > отдельной fs, система при загрузке падает в кернел паник, ибо
>  > невозможно стартовать /sbin/init.
> Спасибо за еще несколько бит информации про systemd... У Поттеринга всё
> работает, ага...

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

Re: zfs on linux

[Artem Chuprina]

Alex Kicelew -> debian-russian@lists.debian.org  @ Sun, 9 Jul 2017 17:07:47 
+0300:

 > 3) systemd запускается раньше, чем монтируются некорневые fs в составе
 > zfs, поэтому сервисы, закросслинканные на файлы на некорневых fs при
 > старте systemd не видны. И если ожидается, что они автостартуют при
 > загрузке, то ожидается зря. Они станут видны systemd только после того,
 > как появится возможность сказать sudo systemctl daemon-reload (и, если
 > нужно, отдельно systemctl --user daemon-reload), после чего их нужно
 > будет стартовать руками.

 > Отдельно стоит отметить, что /sbin/init в лице systemd в настоящее время
 > (версия 233-9) слинкован в числе прочего с одной библиотекой из
 > /usr/lib. Я не смотрел, до инита монтируются некорневые fs на обычных
 > системах, или после,

После. Точно так же. Так что идея линковать сервисы в некорневую fs
относится к плохим. Прочесть конфиг, где написано "давай подождем, пока
вон то смонтируется" надо все же раньше, чем оно смонтируется.

 > но в zfs -- точно после, в результате чего если /usr расположен на
 > отдельной fs, система при загрузке падает в кернел паник, ибо
 > невозможно стартовать /sbin/init.

Спасибо за еще несколько бит информации про systemd... У Поттеринга всё
работает, ага...

 > 4) swap внутри zfs работает вполне корректно, но, вероятно, hibernate
 > работать в таком режиме не будет, ибо насколько я понял, обращение за
 > сохраненными данными идет до импорта пула.

Вообще это вот надо внимательно посмотреть... Насколько я понимаю
ситуацию, например, с LVM, то там тома все же должны подниматься до
того, начинает отрабатывать hibernate. Чтобы понять, откуда. А файловые
системы подхватываться — уже после, на основании поднятых гибернейтом
данных.

Надо бы потестировать на виртуалке...

Re: zfs on linux

[Alex Kicelew]

On 07/08/17 13:54, Alex Kicelew wrote:
> диск, подключенный по usb. На диск, вставленный в гнездо, все
> поставилось нормально. Правда, не работает... :(

Вроде бы, все проблемы победились. Но интеграция zfs в дебиан пока еще
далеко не полная. Грабли, по которым я прошел:

1) оказалось, что мой usb-переходник врет геометрию дисков (в частности,
512-байтные сектора передает как 4-килобайтные), что, разумеется, не
проблема zfs, но время отняло.

2) мой ноут умеет грузиться как с bios boot, так и с uefi, но, как
оказалось, с диска, размеченного в gpt (а в хауту описано именно это) он
умеет грузиться только с uefi. Bios boot, расположенный на gpt, он не
понимает. Это тоже не проблема zfs.

3) systemd запускается раньше, чем монтируются некорневые fs в составе
zfs, поэтому сервисы, закросслинканные на файлы на некорневых fs при
старте systemd не видны. И если ожидается, что они автостартуют при
загрузке, то ожидается зря. Они станут видны systemd только после того,
как появится возможность сказать sudo systemctl daemon-reload (и, если
нужно, отдельно systemctl --user daemon-reload), после чего их нужно
будет стартовать руками.

Отдельно стоит отметить, что /sbin/init в лице systemd в настоящее время
(версия 233-9) слинкован в числе прочего с одной библиотекой из
/usr/lib. Я не смотрел, до инита монтируются некорневые fs на обычных
системах, или после, но в zfs -- точно после, в результате чего если
/usr расположен на отдельной fs, система при загрузке падает в кернел
паник, ибо невозможно стартовать /sbin/init.

4) swap внутри zfs работает вполне корректно, но, вероятно, hibernate
работать в таком режиме не будет, ибо насколько я понял, обращение за
сохраненными данными идет до импорта пула.

А так в целом работает. Отличий в скорости на глаз не заметно вообще.

Re: zfs on linux

[Aleksandr Sytar]

8 июля 2017 г., 15:23 пользователь Sergey Matveev 
написал:

>
> Я как-то встречал один USB<->SATA контроллер (внешний контейнер) который
> действительно чуть "смещал" данные. То есть диск выглядел как немного
> уменьшенный по размеру. Данных вроде туда не писал никаких дополнительных,
> но вот почему-то геометрия была чуть другой.
>
>
Надо смотреть как он кластера представляет - я видел переходники которые
говорят что на диске 4K кластера (хотя на самом деле они 512)

Re: zfs on linux

[Sergey Matveev]

*** Alex Kicelew  [2017-07-08 13:55]:
>Эта проблема решена. Вероятно, дурак -- я, а не zfs (хотя я до конца так
>и не понял, в чем именно). Причина была в том, что я устанавливал zfs на
>диск, подключенный по usb. На диск, вставленный в гнездо, все
>поставилось нормально. Правда, не работает... :(

Я как-то встречал один USB<->SATA контроллер (внешний контейнер) который
действительно чуть "смещал" данные. То есть диск выглядел как немного
уменьшенный по размеру. Данных вроде туда не писал никаких дополнительных,
но вот почему-то геометрия была чуть другой.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: zfs on linux

[Alex Kicelew]

On 07/06/17 13:19, Alex Kicelew wrote:
> у меня же возвращается:
> # grub-probe /
> grub-probe: error: unknown filesystem.

Эта проблема решена. Вероятно, дурак -- я, а не zfs (хотя я до конца так
и не понял, в чем именно). Причина была в том, что я устанавливал zfs на
диск, подключенный по usb. На диск, вставленный в гнездо, все
поставилось нормально. Правда, не работает... :(

Прошли все этапы установки. Разбит диск, создана и разбита fs,
скопирована система, в нее сделан чрут, корень определяется, как zfs,
сделан update-initramfs (прошел корректно), сделан update-grub (прошел
корректно), сделан grub-install (прошел корректно), все отмонтировано.

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

Груб из стретча (вначале был из тестинга, там он уже более новый)
пробовался, то же самое.

Можно ли еще куда-то попробовать покопать?

Re: zfs on linux

[Alex Kicelew]

On 07/06/17 17:31, Dmitry Kulagin wrote:
> Может grub-pc из Stretch попробовать?..

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

Re: zfs on linux

[Dmitry Kulagin]

06.07.2017 16:31, Alex Kicelew пишет:

On 07/06/17 15:41, Dmitry Kulagin wrote:

zfs send|receive переносил установку  на еще 9, соответственно
процедура создания пулов, фс и установка grub прошла 10 раз
без проблем, загружался и устанавливал с флешки, на которой был

То, что проблема возникает не всегда, радует. Но интересно, как с ней
бороться, если она возникла. :)

Может grub-pc из Stretch попробовать?..

Re: zfs on linux

[Alex Kicelew]

On 07/06/17 15:41, Dmitry Kulagin wrote:
> zfs send|receive переносил установку  на еще 9, соответственно
> процедура создания пулов, фс и установка grub прошла 10 раз
> без проблем, загружался и устанавливал с флешки, на которой был

То, что проблема возникает не всегда, радует. Но интересно, как с ней
бороться, если она возникла. :)

> А Вы старый диск заного переразбивали или новый, чистый? Для старого
> иногда надо перезагружаться, если его какой-нибудь udisk2 или аналог
> зацепит?

Новый. До перезагрузки пока не дошло -- груб не прописывается.

Re: zfs on linux

[Dmitry Kulagin]

2 месяца назад устанавливал по этому хелпу Debian Stretch
(на тот момент testing) на первую машину, а потом с помощью
zfs send|receive переносил установку  на еще 9, соответственно
процедура создания пулов, фс и установка grub прошла 10 раз
без проблем, загружался и устанавливал с флешки, на которой был
установлен все тот же, текущий на тот момент, Stretch. Во время
установки столкнулся с единственной проблемой: из-за systemd
невозможно было отмонтировать новый корень, он почему-то его
не отпускал, поэтому приходилось после перезагрузки, снова
загружаться с флешки и делать:
zpool import rpool
zpool export rpool
и перегружаться снова уже в новую систему.
Кстати, примерно год назад или больше в тестинге zfs + systemd
комбинация была вообще сломана: при перезагрузки системы
zfs вообще не отмонтировали, интересно, как оно в Jessie+backports?
А Вы старый диск заного переразбивали или новый, чистый? Для старого
иногда надо перезагружаться, если его какой-нибудь udisk2 или аналог
зацепит?

06.07.2017 13:19, Alex Kicelew пишет:

Hi

А есть ли кто-нибудь, сидящий на сабже? Попробовал установить по
https://github.com/zfsonlinux/zfs/wiki/Debian-Jessie-Root-on-ZFS,
столкнулся с проблемой.

Отличия моей конфигурации от хаутушки: у меня отродясь на ноуте тестинг,
кроме того, сейчас он уже поверх stretch, а не jessy, как в хауту,
поэтому не делал никаких танцев с бубном вокруг jessie-backports, взял
zfs-dkms и zfs-initramfs из тестинга, груб оттуда же по умолчанию. Кроме
того, я не ставил систему с нуля, а полностью скопировал ее рсинком с
рабочей. Все остальное по хауту.

Проблема:

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

# grub-probe /
zfs

у меня же возвращается:

# grub-probe /
grub-probe: error: unknown filesystem.

-vvv выдает:

# grub-probe -vvv /new 2>&1 | grep -i zfs
grub-core/kern/fs.c:56: Detecting zfs...
grub-core/fs/zfs/zfs.c:1192: label ok 0
grub-core/fs/zfs/zfs.c:1007: check 2 passed
grub-core/fs/zfs/zfs.c:1018: check 3 passed
grub-core/fs/zfs/zfs.c:1025: check 4 passed
grub-core/fs/zfs/zfs.c:1035: check 6 passed
grub-core/fs/zfs/zfs.c:1043: check 7 passed
grub-core/fs/zfs/zfs.c:1054: check 8 passed
grub-core/fs/zfs/zfs.c:1064: check 9 passed
grub-core/fs/zfs/zfs.c:1086: check 11 passed
grub-core/fs/zfs/zfs.c:1112: check 10 passed
grub-core/fs/zfs/zfs.c:1128: str=com.delphix:hole_birth
grub-core/fs/zfs/zfs.c:1128: str=com.delphix:embedded_data
grub-core/fs/zfs/zfs.c:1137: check 12 passed (feature flags)
grub-core/fs/zfs/zfs.c:1878: zio_read: E 0: size 2048/2048
grub-core/fs/zfs/zfs.c:1899: endian = -1
grub-core/fs/zfs/zfs.c:595: dva=8, 1908c4f8
grub-core/fs/zfs/zfs.c:442: checksum fletcher4 verification failed
grub-core/fs/zfs/zfs.c:447: actual checksum 0082598c98ea
88a0c7f16104 005d0b808f380960 2f51aa5e372675ef
grub-core/fs/zfs/zfs.c:452: expected checksum 0004f5f43504
09254c38ba95 00087352d4a8f77f 0537bd0ed13060ad
grub-core/fs/zfs/zfs.c:1922: incorrect checksum
grub-core/kern/fs.c:78: zfs detection failed.

Гугление показало, что проблема известна с 12 года и тогда же запатчена.
А потом запатчена в 14. Но вплоть по 16 год встречаются сообщения с той
же проблемой и с вопросом: а делать-то че? Насколько я понял, проблема
может возникнуть на ровном месте при очередном апдейте, приведшем к
перегенерации загрузочной информации. scrub ее не лечит (у меня просто
не видит -- диск чистый), от типа чексумм, вроде, тоже не зависит (у
меня, правда, по умолчанию тот же флетчер4, но в нагуглившихся репортах
народ недоумевает: какой, нафиг, флетчер, если у меня везде sha-256).

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

На всякий случай:

zfs-dkms 0.6.5.9-5
grub-pc 2.02-1

Re: ZFS

[artiom]

Любопытно, что GRUB может загружать ОС с ZFS снапшота:

"On ZFS filesystem the first path component must be volume‘@’[snapshot].
So ‘/rootvol@snap-129/boot/grub/grub.cfg’ refers to file
‘/boot/grub/grub.cfg’ in snapshot of volume ‘rootvol’ with name
‘snap-129’. Trailing ‘@’ after volume name is mandatory even if snapshot
name is omitted."


https://www.gnu.org/software/grub/manual/html_node/File-name-syntax.html#File-name-syntax

Re: ZFS

[Savitskiy EM]

On Sun, Jun 25, 2017 at 03:58:54PM +0300, Artem Chuprina wrote:
> Vasiliy P. Melnik -> debian-russian  @ Sun, 25 Jun 2017 12:01:00 +0300:
> 
>  > Если мы говорим о системе из трех дисков и говорим о дебиан 9 - я проверял,
>  > граб наконец-то научился бутить кернел из лвм-раздела. Я бы поспуил
>  > следующим образом
>  > 1) выделить на каждом диске раздел в начала 80 гигов
>  > 2) создать второй раздел
>  > 3) создать рейд1 и в него включить этих три раздела.
>  > 4) поверх рейда создать лвм-раздел
> 
> А вот это зачем? Система - она и есть система, там весь раздел под нее
> отводится, что там делать LVM'у? Типа, чтобы сделать только один рейд, и
> своп держать на нем же, а не два зеркала, один для системы, другой для
> свопа?

Ну если есть возможность докупить потом дисков и расширить RAID, то LVM 
позволит расширить и разделы FS

> 
>  > 5) поставить систему на этот лвм
>  > 6) установить зфс модули в систему
>  > 7) из оставшихся трех раздел собрать пул raidz
> 
> 
>  > 24 июня 2017 г., 15:01 пользователь Artem Chuprina 
>  > написал:
> 
>  >> Граждане, раз уж пошла такая пьянка.
>  >>
>  >> Я правильно понимаю, что если я, допустим, хочу хранить
>  >> бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки ставить
>  >> на нормальный раздел, а не на zfs же? А zfs разворачивать поверх второго
>  >> раздела?
>  >>
>  >> А если я, допустим, хочу рейд на нескольких дисках, то поделить каждый
>  >> так же на два раздела, на первых сделать raid1 с системой, а на вторых
>  >> собирать raidz?
>  >>
>  >> Потому что систему на zfs я если и водружу, то в случае сбоя хрен я к
>  >> файловой системе штатными средствами бутовой флешки доберусь?
>  >>
>  >> Это я задумываюсь про апгрейд двух серверов - домашнего, который он же
>  >> файлообменник, и бэкап-сервера на работе. Дома в норме один диск, на
>  >> работе - рейд.
>  >>
>  >> И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта суммой
>  >> из всего этого уже забито, я собираюсь ставить 4-терабайтник,
>  >> вероятно. На работе имеется в виду держать зеркало из пары
>  >> 4-терабайтников.
>  >>
>  >> В обоих случаях супербыстрый доступ не требуется, но и суровых тормозов
>  >> быть не должно.
>  >>
>  >> Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
>  >> более-менее комфортно? А если я захочу дедупликацию включить?  (Кстати,
>  >> ее можно включить/выключить на ходу, или это надо делать в момент
>  >> создания FS?)
>  >>
>  >>
> 
> 

Re: ZFS

[Vasiliy P. Melnik]

>
> Внезапного выключения питания не бывает, если не сдохли аккумуляторы в ИБП.
>

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

Re: ZFS

[Михаил Касаджиков]

Artem Chuprina  писал(а) в своём письме Sun, 25 Jun 2017 
15:56:32 +0300:


artiom -> debian-russian@lists.debian.org  @ Sun, 25 Jun 2017 13:59:32 +0300:

 >> Я бы поспуил следующим образом
 >> 1) выделить на каждом диске раздел в начала 80 гигов
 >> 2) создать второй раздел
 >> 3) создать рейд1 и в него включить этих три раздела.
 > Зачем?
 > Ради защиты от падения ОС?
 > А выделить под ОС, например SSD?

Я вот на ноуте, с которого сейчас пишу (ASUS Zenbook, какой - лень
смотреть), поначалу выделил SSD под ОС... Хватило ума сделать на
нормальном винте такой же раздел с копией. После того, как у меня пару
раз на ровном месте побились существеные для работы системы файлы, я SSD
из употребления вывел. И затаил...


Я года три назад прочитал статью про «петабайтный тест» и купил Corsair Neutron 
GTX на 240 гиг, ровно такой же как и в статье, на замену HDD в ноуте. Даже не 
смотря на SATA2 работа с диском стала заметно шустрее. Защиту от падения SSD 
возложил на ежедневное резервное копирование всех разделов на домашний NAS, 
1-го числа полный архив и ежедневная разница. Работает и не жужжит, помирать 
пока не собирается.

smartctl:
Device Model: Corsair Neutron GTX SSD
Serial Number:1420791600010079006A
Firmware Version: M312
User Capacity:240 057 409 536 bytes [240 GB]
…
SMART Attributes Data Structure revision number: 0
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE  UPDATED  
WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate 0x000e   166   156   006Old_age   Always   
-   0
  5 Reallocated_Sector_Ct   0x0032   098   098   036Old_age   Always   
-   291
  9 Power_On_Hours  0x0032   076   076   000Old_age   Always   
-   21273
 12 Power_Cycle_Count   0x0032   100   100   000Old_age   Always   
-   728
171 Unknown_Attribute   0x0032   253   253   000Old_age   Always   
-   0
172 Unknown_Attribute   0x0032   100   100   000Old_age   Always   
-   300
181 Program_Fail_Cnt_Total  0x0032   253   253   000Old_age   Always   
-   0
182 Erase_Fail_Count_Total  0x0032   100   100   000Old_age   Always   
-   300
194 Temperature_Celsius 0x0002   035   000   000Old_age   Always   
-   35 (Min/Max 16/57)
201 Unknown_SSD_Attribute   0x000e   039   001   000Old_age   Always   
-   1126
204 Soft_ECC_Correction 0x000e   100   100   000Old_age   Always   
-   0
231 Temperature_Celsius 0x0033   092   092   010Pre-fail  Always   
-   9
234 Unknown_Attribute   0x0032   100   100   000Old_age   Always   
-   123974
241 Total_LBAs_Written  0x0032   100   100   000Old_age   Always   
-   4315
242 Total_LBAs_Read 0x0032   100   100   000Old_age   Always   
-   17351
250 Read_Error_Retry_Rate   0x0032   100   100   000Old_age   Always   
-   341633

231-й а атрибут — состояние в %, сейчас 92%.

--
Написано с помощью почтового клиента Opera: http://www.opera.com/mail/

Re: ZFS

[Sergey B Kirpichev]

On Sun, Jun 25, 2017 at 12:30:07PM +0300, Sergey Matveev wrote:
> Btrfs не умеет аналогов RAID5/RAID6 (в ZFS RAIDZ1/2/3)

Умеет, но говорят что больно бажное.

Re: ZFS

[Sergey B Kirpichev]

On Sun, Jun 25, 2017 at 02:29:29AM +0300, Sergey Matveev wrote:
> Кстати, забыл отметить важное (если не важнейшее) отличие ZFS массивов
> от RAID-ов: проблема write-hole-ов.

Вроде MDRAID от нее таки избавился.

Re: ZFS

[Artem Chuprina]

artiom -> debian-russian@lists.debian.org  @ Mon, 26 Jun 2017 07:20:11 +0300:

 >>  > Причём у меня ОС на SSD и тоже ZenBook.
 >>  > Давно лететь флешка начала?
 >> 
 >> Практически сразу.
 >> 
 >>  > И точно ли это флешка?
 >> 
 >> После вывода ее из употребления несколько лет никаких проблем.
 >> 
 > Ну у меня работает несколько месяцев. Sandisk флешка на 128 Гб, хотя
 > посмотрел вчера: в SMART трэш какой-то. Возможно, всё-таки заводской
 > брак у конкретного ноута?

Не исключено. У меня это единственный опыт с SSD.

Re: ZFS

[artiom]

25.06.2017 19:29, Artem Chuprina пишет:
> artiom -> debian-russian@lists.debian.org  @ Sun, 25 Jun 2017 16:27:21 +0300:
> 
>  > Причём у меня ОС на SSD и тоже ZenBook.
>  > Давно лететь флешка начала?
> 
> Практически сразу.
> 
>  > И точно ли это флешка?
> 
> После вывода ее из употребления несколько лет никаких проблем.
> 
Ну у меня работает несколько месяцев. Sandisk флешка на 128 Гб, хотя
посмотрел вчера: в SMART трэш какой-то. Возможно, всё-таки заводской
брак у конкретного ноута?

Re: ZFS

[Oleksandr Gavenko]

On 2017-06-25, artiom wrote:

> Так рейд поломан будет, он же собраться не должен.

А что на зеркале чтение идет с 2 дисков и затем сравнивается? По причине
производительности мне казалось что чтение будет ити попеременно с накопителей
но никогда одновременно не читаться... 

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

-- 
http://defun.work/

Re: ZFS

[Artem Chuprina]

artiom -> debian-russian@lists.debian.org  @ Sun, 25 Jun 2017 16:27:21 +0300:

 > Причём у меня ОС на SSD и тоже ZenBook.
 > Давно лететь флешка начала?

Практически сразу.

 > И точно ли это флешка?

После вывода ее из употребления несколько лет никаких проблем.

 > 25.06.2017 15:56, Artem Chuprina пишет:
 >> artiom -> debian-russian@lists.debian.org  @ Sun, 25 Jun 2017 13:59:32 
 >> +0300:
 >> 
 >>  >> Я бы поспуил следующим образом
 >>  >> 1) выделить на каждом диске раздел в начала 80 гигов
 >>  >> 2) создать второй раздел
 >>  >> 3) создать рейд1 и в него включить этих три раздела.
 >>  > Зачем?
 >>  > Ради защиты от падения ОС?
 >>  > А выделить под ОС, например SSD?
 >> 
 >> Я вот на ноуте, с которого сейчас пишу (ASUS Zenbook, какой - лень
 >> смотреть), поначалу выделил SSD под ОС... Хватило ума сделать на
 >> нормальном винте такой же раздел с копией. После того, как у меня пару
 >> раз на ровном месте побились существеные для работы системы файлы, я SSD
 >> из употребления вывел. И затаил...
 >> 
 >> То есть вот идею выделить под ОС SSD ради задиты ее от падения... Скорее
 >> наоборот.
 >> 
 >>  >> 4) поверх рейда создать лвм-раздел
 >>  >> 5) поставить систему на этот лвм
 >>  >> 6) установить зфс модули в систему
 >>  >> 7) из оставшихся трех раздел собрать пул raidz
 >>  >> 
 >>  >> 
 >>  >> 24 июня 2017 г., 15:01 пользователь Artem Chuprina >  >> > написал:
 >>  >> 
 >>  >> Граждане, раз уж пошла такая пьянка.
 >>  >> 
 >>  >> Я правильно понимаю, что если я, допустим, хочу хранить
 >>  >> бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки 
 >> ставить
 >>  >> на нормальный раздел, а не на zfs же? А zfs разворачивать поверх 
 >> второго
 >>  >> раздела?
 >>  >> 
 >>  >> А если я, допустим, хочу рейд на нескольких дисках, то поделить 
 >> каждый
 >>  >> так же на два раздела, на первых сделать raid1 с системой, а на 
 >> вторых
 >>  >> собирать raidz?
 >>  >> 
 >>  >> Потому что систему на zfs я если и водружу, то в случае сбоя хрен я 
 >> к
 >>  >> файловой системе штатными средствами бутовой флешки доберусь?
 >>  >> 
 >>  >> Это я задумываюсь про апгрейд двух серверов - домашнего, который он 
 >> же
 >>  >> файлообменник, и бэкап-сервера на работе. Дома в норме один диск, на
 >>  >> работе - рейд.
 >>  >> 
 >>  >> И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта 
 >> суммой
 >>  >> из всего этого уже забито, я собираюсь ставить 4-терабайтник,
 >>  >> вероятно. На работе имеется в виду держать зеркало из пары
 >>  >> 4-терабайтников.
 >>  >> 
 >>  >> В обоих случаях супербыстрый доступ не требуется, но и суровых 
 >> тормозов
 >>  >> быть не должно.
 >>  >> 
 >>  >> Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
 >>  >> более-менее комфортно? А если я захочу дедупликацию включить?  
 >> (Кстати,
 >>  >> ее можно включить/выключить на ходу, или это надо делать в момент
 >>  >> создания FS?)
 >>  >> 
 >>  >> 
 >> 

Re: ZFS

[Sergey Matveev]

*** yuri.nefe...@gmail.com  [2017-06-25 18:34]:
>  У меня SSD умер сразу в одночасье. Сразу получил нерабочий кирпичик.
>  Но я сильно не упорствовал, мне по гарантии его поменяли.
>
>  SMART для SSD не внушает доверия.
>  Скажем, вот вывод smartctl для ноутбучного  SSD (ему более 4 лет):

Ого, сколько у вас информации (пускай и не очень доверяемой). У меня
только power on hours (честно говорит что 3.5 года), power cycle count и
температура. Спасибо за информацию! Собственно, подтверждается то, что
он дохнет сразу, в отличии от HDD.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

[artiom]

25.06.2017 18:32, yuri.nefe...@gmail.com пишет:
> On Sun, 25 Jun 2017, Sergey Matveev wrote:
> 
>> *** Artem Chuprina  [2017-06-25 15:57]:
>>> Я вот на ноуте, с которого сейчас пишу (ASUS Zenbook, какой - лень
>>> смотреть), поначалу выделил SSD под ОС... Хватило ума сделать на
>>> нормальном винте такой же раздел с копией. После того, как у меня пару
>>> раз на ровном месте побились существеные для работы системы файлы, я SSD
>>> из употребления вывел. И затаил...
>>
>> Хочу поинтересоваться: а как умирают SSD диски? В SMART-е они об этом
>> предупредят? Сыпятся частями или сразу полностью? У меня SSD в ноутбуке
>> уже 3.5 года живёт и нагрузка на нём всегда была очень высокая
>> (развернуть 20 гигабайтный PostgreSQL с индексами, по несколько раз в
>> день) и по идее уже давно должен бы был помереть. Если он летит частями,
>> то zfs set copies=2 должно помочь от того когда придёт судный день чтобы
>> успеть сдампить данные на что-то работающее -- это хоть как-то бы
>> успокаивало.
>>
> 
>   У меня SSD умер сразу в одночасье. Сразу получил нерабочий кирпичик.
>   Но я сильно не упорствовал, мне по гарантии его поменяли.
> 
>   SMART для SSD не внушает доверия.
>   Скажем, вот вывод smartctl для ноутбучного  SSD (ему более 4 лет):
> 
>   Power_On_Hours4976
>   глупость какая, что же он меньше года был включен?
> 
>   Host_Reads_GiB2489
>   Host_Writes_GiB   1863
>   Total_NAND_Prog_Ct_GiB306241612
>   Ну и как верить этим числам?
> 
>   Average_Erase_Count   834
>   Remaining_Lifetime_Perc   73
>   Тут похоже можно доверять.
>   Для 25nm MLC памяти максимальное число перезаписей ~3000
>   (3000-834)/3000 = 0.722
> 
> Ю.
Мда, меня мой тоже не порадовал:
Warning! SMART ATA Error Log Structure error: invalid SMART checksum.
SMART Error Log Version: 1
Warning: ATA error count 65535 inconsistent with error log pointer 1

ATA Error Count: 65535 (device log contains only the most recent five
errors)
CR = Command Register [HEX]
FR = Features Register [HEX]
SC = Sector Count Register [HEX]
SN = Sector Number Register [HEX]
CL = Cylinder Low Register [HEX]
CH = Cylinder High Register [HEX]
DH = Device/Head Register [HEX]
DC = Device Command Register [HEX]
ER = Error register [HEX]
ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 65535 occurred at disk power-on lifetime: 65535 hours (2730 days +
15 hours)
  When the command that caused the error occurred, the device was in a
vendor specific state.

Re: ZFS

[yuri . nefedov]

On Sun, 25 Jun 2017, Sergey Matveev wrote:


*** Artem Chuprina  [2017-06-25 15:57]:

Я вот на ноуте, с которого сейчас пишу (ASUS Zenbook, какой - лень
смотреть), поначалу выделил SSD под ОС... Хватило ума сделать на
нормальном винте такой же раздел с копией. После того, как у меня пару
раз на ровном месте побились существеные для работы системы файлы, я SSD
из употребления вывел. И затаил...


Хочу поинтересоваться: а как умирают SSD диски? В SMART-е они об этом
предупредят? Сыпятся частями или сразу полностью? У меня SSD в ноутбуке
уже 3.5 года живёт и нагрузка на нём всегда была очень высокая
(развернуть 20 гигабайтный PostgreSQL с индексами, по несколько раз в
день) и по идее уже давно должен бы был помереть. Если он летит частями,
то zfs set copies=2 должно помочь от того когда придёт судный день чтобы
успеть сдампить данные на что-то работающее -- это хоть как-то бы успокаивало.



  У меня SSD умер сразу в одночасье. Сразу получил нерабочий кирпичик.
  Но я сильно не упорствовал, мне по гарантии его поменяли.

  SMART для SSD не внушает доверия.
  Скажем, вот вывод smartctl для ноутбучного  SSD (ему более 4 лет):

  Power_On_Hours4976
  глупость какая, что же он меньше года был включен?

  Host_Reads_GiB2489
  Host_Writes_GiB   1863
  Total_NAND_Prog_Ct_GiB306241612
  Ну и как верить этим числам?

  Average_Erase_Count   834
  Remaining_Lifetime_Perc   73
  Тут похоже можно доверять.
  Для 25nm MLC памяти максимальное число перезаписей ~3000
  (3000-834)/3000 = 0.722

Ю.

Re: ZFS

[artiom]

25.06.2017 16:29, Sergey Matveev пишет:
> *** artiom  [2017-06-25 16:27]:
>> Так рейд поломан будет, он же собраться не должен.
> 
> То есть, при внезапной поломке, мы понимаем что данные неконсистенты и
> считает что проще всё восстановить извне, типа как-будто это равносильно
> пропаже данных?
Конечно. Восстановление на уровне выше "железного".
Потому всяким гуглам и выгодно контейнеры из "обычного" железа собирать:
сломалось - поменял, т.к. дёшево, данные же реплицированы в разных
местах, им ничто не угрожает, даже локальные катаклизмы.

Re: ZFS

[Sergey Matveev]

*** artiom  [2017-06-25 16:27]:
>Так рейд поломан будет, он же собраться не должен.

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

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

[artiom]

Причём у меня ОС на SSD и тоже ZenBook.
Давно лететь флешка начала?
И точно ли это флешка?

25.06.2017 15:56, Artem Chuprina пишет:
> artiom -> debian-russian@lists.debian.org  @ Sun, 25 Jun 2017 13:59:32 +0300:
> 
>  >> Я бы поспуил следующим образом
>  >> 1) выделить на каждом диске раздел в начала 80 гигов
>  >> 2) создать второй раздел
>  >> 3) создать рейд1 и в него включить этих три раздела.
>  > Зачем?
>  > Ради защиты от падения ОС?
>  > А выделить под ОС, например SSD?
> 
> Я вот на ноуте, с которого сейчас пишу (ASUS Zenbook, какой - лень
> смотреть), поначалу выделил SSD под ОС... Хватило ума сделать на
> нормальном винте такой же раздел с копией. После того, как у меня пару
> раз на ровном месте побились существеные для работы системы файлы, я SSD
> из употребления вывел. И затаил...
> 
> То есть вот идею выделить под ОС SSD ради задиты ее от падения... Скорее
> наоборот.
> 
>  >> 4) поверх рейда создать лвм-раздел
>  >> 5) поставить систему на этот лвм
>  >> 6) установить зфс модули в систему
>  >> 7) из оставшихся трех раздел собрать пул raidz
>  >> 
>  >> 
>  >> 24 июня 2017 г., 15:01 пользователь Artem Chuprina   >> > написал:
>  >> 
>  >> Граждане, раз уж пошла такая пьянка.
>  >> 
>  >> Я правильно понимаю, что если я, допустим, хочу хранить
>  >> бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки ставить
>  >> на нормальный раздел, а не на zfs же? А zfs разворачивать поверх 
> второго
>  >> раздела?
>  >> 
>  >> А если я, допустим, хочу рейд на нескольких дисках, то поделить каждый
>  >> так же на два раздела, на первых сделать raid1 с системой, а на вторых
>  >> собирать raidz?
>  >> 
>  >> Потому что систему на zfs я если и водружу, то в случае сбоя хрен я к
>  >> файловой системе штатными средствами бутовой флешки доберусь?
>  >> 
>  >> Это я задумываюсь про апгрейд двух серверов - домашнего, который он же
>  >> файлообменник, и бэкап-сервера на работе. Дома в норме один диск, на
>  >> работе - рейд.
>  >> 
>  >> И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта суммой
>  >> из всего этого уже забито, я собираюсь ставить 4-терабайтник,
>  >> вероятно. На работе имеется в виду держать зеркало из пары
>  >> 4-терабайтников.
>  >> 
>  >> В обоих случаях супербыстрый доступ не требуется, но и суровых 
> тормозов
>  >> быть не должно.
>  >> 
>  >> Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
>  >> более-менее комфортно? А если я захочу дедупликацию включить?  
> (Кстати,
>  >> ее можно включить/выключить на ходу, или это надо делать в момент
>  >> создания FS?)
>  >> 
>  >> 
> 

Re: ZFS

[artiom]

25.06.2017 16:24, Sergey Matveev пишет:
> *** artiom  [2017-06-25 16:22]:
>> В три датацентра данные реплицировались, в одном машина сдохла.
>> Вопросов о консистентности не стоит.
> 
> Пропажа данных, недоступность -- это одно. А когда вот у вас лежат
> данные, а вы даже не подозреваете что они испорчены.
> 
Так рейд поломан будет, он же собраться не должен.

Re: ZFS

[Sergey Matveev]

*** artiom  [2017-06-25 16:22]:
>В три датацентра данные реплицировались, в одном машина сдохла.
>Вопросов о консистентности не стоит.

Пропажа данных, недоступность -- это одно. А когда вот у вас лежат
данные, а вы даже не подозреваете что они испорчены.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

[artiom]

25.06.2017 14:12, Sergey Matveev пишет:
> *** artiom  [2017-06-25 14:06]:
>>> Бывает внезапная поломка backplane, контроллера, блока питания,
>>> материнской платы, итд.
>>>
>> Не поможет тогда контроллер.
> 
> Ну в случае выхода контроллера -- да. Если backplane или что-то
> остальное, то поможет -- запустить на работающей системе.
> 
>> К тому же, это для каких-то очень критичных систем.
>> А там, как правило, данные по нескольким разным машинам/датацентрам
>> реплицируются, и проблема тоже не сильно актуальна.
> 
> Проблема того что у вас есть возможность получить неконсистентные
> данные, испорченные. По моему это очень критично, независимо от задач. У
> нас же ЭВМ, куча миллиардов инструкций, гигабайты хранилищ, а данные
> могут быть потеряны... не порядок это.
> 
В три датацентра данные реплицировались, в одном машина сдохла.
Вопросов о консистентности не стоит.

Re: ZFS

[artiom]

25.06.2017 15:56, Artem Chuprina пишет:
> artiom -> debian-russian@lists.debian.org  @ Sun, 25 Jun 2017 13:59:32 +0300:
> 
>  >> Я бы поспуил следующим образом
>  >> 1) выделить на каждом диске раздел в начала 80 гигов
>  >> 2) создать второй раздел
>  >> 3) создать рейд1 и в него включить этих три раздела.
>  > Зачем?
>  > Ради защиты от падения ОС?
>  > А выделить под ОС, например SSD?
> 
> Я вот на ноуте, с которого сейчас пишу (ASUS Zenbook, какой - лень
> смотреть), поначалу выделил SSD под ОС... Хватило ума сделать на
> нормальном винте такой же раздел с копией. После того, как у меня пару
> раз на ровном месте побились существеные для работы системы файлы, я SSD
> из употребления вывел. И затаил...
> 
o.O
У меня сейчас на SSD crypto и а нём ОС.

> То есть вот идею выделить под ОС SSD ради задиты ее от падения... Скорее
> наоборот.
> 
>  >> 4) поверх рейда создать лвм-раздел
>  >> 5) поставить систему на этот лвм
>  >> 6) установить зфс модули в систему
>  >> 7) из оставшихся трех раздел собрать пул raidz
>  >> 
>  >> 
>  >> 24 июня 2017 г., 15:01 пользователь Artem Chuprina   >> > написал:
>  >> 
>  >> Граждане, раз уж пошла такая пьянка.
>  >> 
>  >> Я правильно понимаю, что если я, допустим, хочу хранить
>  >> бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки ставить
>  >> на нормальный раздел, а не на zfs же? А zfs разворачивать поверх 
> второго
>  >> раздела?
>  >> 
>  >> А если я, допустим, хочу рейд на нескольких дисках, то поделить каждый
>  >> так же на два раздела, на первых сделать raid1 с системой, а на вторых
>  >> собирать raidz?
>  >> 
>  >> Потому что систему на zfs я если и водружу, то в случае сбоя хрен я к
>  >> файловой системе штатными средствами бутовой флешки доберусь?
>  >> 
>  >> Это я задумываюсь про апгрейд двух серверов - домашнего, который он же
>  >> файлообменник, и бэкап-сервера на работе. Дома в норме один диск, на
>  >> работе - рейд.
>  >> 
>  >> И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта суммой
>  >> из всего этого уже забито, я собираюсь ставить 4-терабайтник,
>  >> вероятно. На работе имеется в виду держать зеркало из пары
>  >> 4-терабайтников.
>  >> 
>  >> В обоих случаях супербыстрый доступ не требуется, но и суровых 
> тормозов
>  >> быть не должно.
>  >> 
>  >> Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
>  >> более-менее комфортно? А если я захочу дедупликацию включить?  
> (Кстати,
>  >> ее можно включить/выключить на ходу, или это надо делать в момент
>  >> создания FS?)
>  >> 
>  >> 
> 

Re: ZFS

[Artem Chuprina]

Sergey Matveev -> debian-russian@lists.debian.org  @ Sun, 25 Jun 2017 16:02:18 
+0300:

 >>Я вот на ноуте, с которого сейчас пишу (ASUS Zenbook, какой - лень
 >>смотреть), поначалу выделил SSD под ОС... Хватило ума сделать на
 >>нормальном винте такой же раздел с копией. После того, как у меня пару
 >>раз на ровном месте побились существеные для работы системы файлы, я SSD
 >>из употребления вывел. И затаил...

 > Хочу поинтересоваться: а как умирают SSD диски? В SMART-е они об этом
 > предупредят? Сыпятся частями или сразу полностью?

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

Re: ZFS

[Sergey Matveev]

*** artiom  [2017-06-25 16:05]:
>Короче, под почту и логи он не подходит явно.

Просто выставьте размер записи не по-умолчанию в 128 KiB, а 4 или меньше.

>А, вот оно как...
>Но при создании ФС я задаю размер?
>Просто могу расширить в будущем, если место в пуле есть?

Нет, размер ФС вы не задаёте, он просто берётся из pool-а. Это,
как-будто, вы создали просто директорию -- место для неё берётся из того
что имеется. reservation это действительно резервирование места, его
можно задать когда угодно.

В ZFS в 99% времени используют только две команды: zpool и zfs. zpool
это управление железными дисками, массивами и тому прочим. Это pool --
штука которая что-то там может как-то хранить. А поверх этого хранилища
уже создаются высокоуровневые файловые системы ZFS, командой zfs. Место
pool-а из коробки доступно всем созданным ФС:

# zfs list
NAME USED  AVAIL  REFER  MOUNTPOINT
zroot   37.1G  49.1G  5.95G  none
zroot/home  9.50G  49.1G  6.99G  /home
zroot/home/tmp  2.19G  49.1G  2.19G  /home/stargrave/tmp

это вот у меня говорит что для трёх ФС (zroot, zroot/home,
zroot/home/tmp) доступно одни и те же 49.1 GB.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

[artiom]

>> Он упаковку мелких файлов в один блок, как reiserfs, умеет?
> 
> Он может динамически менять размер блока (как конкретно -- не знаю). Но
> нет, в один блок засунуть несколько "данных" не может (как ещё кстати и
> XFS умеет).
>
Короче, под почту и логи он не подходит явно.

>> Ok. Но он его будет использовать для своих нужд?
>> И что будет, когда квота выйдет, просто скажет, что места не осталось?
> 
> Да, на системе для которой место не было зарезервивано он скажет что
> места не осталось. Тут резервируется место для filesystem, но свободное
> место для проблемы фрагментации должно быть не на filesystem, а на
> pool-е. Pool может содержать несколько filesystem (всё это термины в
> контексте ZFS). Поэтому это место на пуле будет использоваться само
> собой, оно не прикасаемое. reservation это просто квота для отдельной
> filesystem (грубо говоря, директории).
> 
А, вот оно как...
Но при создании ФС я задаю размер?
Просто могу расширить в будущем, если место в пуле есть?

Re: ZFS

[Sergey Matveev]

*** Artem Chuprina  [2017-06-25 15:57]:
>Я вот на ноуте, с которого сейчас пишу (ASUS Zenbook, какой - лень
>смотреть), поначалу выделил SSD под ОС... Хватило ума сделать на
>нормальном винте такой же раздел с копией. После того, как у меня пару
>раз на ровном месте побились существеные для работы системы файлы, я SSD
>из употребления вывел. И затаил...

Хочу поинтересоваться: а как умирают SSD диски? В SMART-е они об этом
предупредят? Сыпятся частями или сразу полностью? У меня SSD в ноутбуке
уже 3.5 года живёт и нагрузка на нём всегда была очень высокая
(развернуть 20 гигабайтный PostgreSQL с индексами, по несколько раз в
день) и по идее уже давно должен бы был помереть. Если он летит частями,
то zfs set copies=2 должно помочь от того когда придёт судный день чтобы
успеть сдампить данные на что-то работающее -- это хоть как-то бы успокаивало.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

[Artem Chuprina]

Vasiliy P. Melnik -> debian-russian  @ Sun, 25 Jun 2017 12:01:00 +0300:

 > Если мы говорим о системе из трех дисков и говорим о дебиан 9 - я проверял,
 > граб наконец-то научился бутить кернел из лвм-раздела. Я бы поспуил
 > следующим образом
 > 1) выделить на каждом диске раздел в начала 80 гигов
 > 2) создать второй раздел
 > 3) создать рейд1 и в него включить этих три раздела.
 > 4) поверх рейда создать лвм-раздел

А вот это зачем? Система - она и есть система, там весь раздел под нее
отводится, что там делать LVM'у? Типа, чтобы сделать только один рейд, и
своп держать на нем же, а не два зеркала, один для системы, другой для
свопа?

 > 5) поставить систему на этот лвм
 > 6) установить зфс модули в систему
 > 7) из оставшихся трех раздел собрать пул raidz


 > 24 июня 2017 г., 15:01 пользователь Artem Chuprina 
 > написал:

 >> Граждане, раз уж пошла такая пьянка.
 >>
 >> Я правильно понимаю, что если я, допустим, хочу хранить
 >> бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки ставить
 >> на нормальный раздел, а не на zfs же? А zfs разворачивать поверх второго
 >> раздела?
 >>
 >> А если я, допустим, хочу рейд на нескольких дисках, то поделить каждый
 >> так же на два раздела, на первых сделать raid1 с системой, а на вторых
 >> собирать raidz?
 >>
 >> Потому что систему на zfs я если и водружу, то в случае сбоя хрен я к
 >> файловой системе штатными средствами бутовой флешки доберусь?
 >>
 >> Это я задумываюсь про апгрейд двух серверов - домашнего, который он же
 >> файлообменник, и бэкап-сервера на работе. Дома в норме один диск, на
 >> работе - рейд.
 >>
 >> И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта суммой
 >> из всего этого уже забито, я собираюсь ставить 4-терабайтник,
 >> вероятно. На работе имеется в виду держать зеркало из пары
 >> 4-терабайтников.
 >>
 >> В обоих случаях супербыстрый доступ не требуется, но и суровых тормозов
 >> быть не должно.
 >>
 >> Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
 >> более-менее комфортно? А если я захочу дедупликацию включить?  (Кстати,
 >> ее можно включить/выключить на ходу, или это надо делать в момент
 >> создания FS?)
 >>
 >>

Re: ZFS

[Artem Chuprina]

artiom -> debian-russian@lists.debian.org  @ Sun, 25 Jun 2017 13:59:32 +0300:

 >> Я бы поспуил следующим образом
 >> 1) выделить на каждом диске раздел в начала 80 гигов
 >> 2) создать второй раздел
 >> 3) создать рейд1 и в него включить этих три раздела.
 > Зачем?
 > Ради защиты от падения ОС?
 > А выделить под ОС, например SSD?

Я вот на ноуте, с которого сейчас пишу (ASUS Zenbook, какой - лень
смотреть), поначалу выделил SSD под ОС... Хватило ума сделать на
нормальном винте такой же раздел с копией. После того, как у меня пару
раз на ровном месте побились существеные для работы системы файлы, я SSD
из употребления вывел. И затаил...

То есть вот идею выделить под ОС SSD ради задиты ее от падения... Скорее
наоборот.

 >> 4) поверх рейда создать лвм-раздел
 >> 5) поставить систему на этот лвм
 >> 6) установить зфс модули в систему
 >> 7) из оставшихся трех раздел собрать пул raidz
 >> 
 >> 
 >> 24 июня 2017 г., 15:01 пользователь Artem Chuprina > > написал:
 >> 
 >> Граждане, раз уж пошла такая пьянка.
 >> 
 >> Я правильно понимаю, что если я, допустим, хочу хранить
 >> бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки ставить
 >> на нормальный раздел, а не на zfs же? А zfs разворачивать поверх второго
 >> раздела?
 >> 
 >> А если я, допустим, хочу рейд на нескольких дисках, то поделить каждый
 >> так же на два раздела, на первых сделать raid1 с системой, а на вторых
 >> собирать raidz?
 >> 
 >> Потому что систему на zfs я если и водружу, то в случае сбоя хрен я к
 >> файловой системе штатными средствами бутовой флешки доберусь?
 >> 
 >> Это я задумываюсь про апгрейд двух серверов - домашнего, который он же
 >> файлообменник, и бэкап-сервера на работе. Дома в норме один диск, на
 >> работе - рейд.
 >> 
 >> И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта суммой
 >> из всего этого уже забито, я собираюсь ставить 4-терабайтник,
 >> вероятно. На работе имеется в виду держать зеркало из пары
 >> 4-терабайтников.
 >> 
 >> В обоих случаях супербыстрый доступ не требуется, но и суровых тормозов
 >> быть не должно.
 >> 
 >> Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
 >> более-менее комфортно? А если я захочу дедупликацию включить?  (Кстати,
 >> ее можно включить/выключить на ходу, или это надо делать в момент
 >> создания FS?)
 >> 
 >> 

Re: ZFS

[Sergey Matveev]

*** Artem Chuprina  [2017-06-25 15:40]:
>В zfs есть понятие "переключиться на такой-то снапшот" в смысле сделать
>так, что в качестве основного состояния FS будет подключен он? И оно это
>запомнит через перезагрузку? Если так, то это интересно...

Во-первых, можно просто откатить состояние ФС до заданного snapshot:

# zfs rollback mypool@snapshotname

Во-вторых, любой snapshot по-умолчанию доступен ещё и вот так, без
необходимости делать rollback:

/mypool-mountpoint/.zfs/snapshot/snapshotname

Ещё есть zfs diff команда, которая может показать diff, с точки зрения
файлов/директори:

# zfs diff zroot@backup
M   /
M   /boot
M   /var
M   /root
+   /var/run/clean_var
+   /var/spool/lock/clean_var
+   /var/run/ld-elf.so.hints
+   /var/run/ld-elf32.so.hints
+   /entropy
[...]
+   /var/log/Xorg.0.log.old
-   /var/log/Xorg.0.log

Причём делает она это быстро, опять же из-за деревьев Меркле внутри ZFS.

> > 8 гигабайт точно хватит, а вот с 4-мя терзают сомнения. А вот если
> > хочется включить дедупликацию, то, личного опыта нет, но говорят что
> > нужно примерно 5 гигабайт RAM на каждый терабайт данных. То есть в
> > случае с 4 TB дисками, лучше бы иметь более 20 гигабайт. Дедупликацию
> > можно включить на уже работающей системе, когда угодно, как и выключить.
> > А точно вам нужна дедупликация? Вот например прозрачное сжатие LZ4 штука
> > я считаю почти всегда не помешающая (zfs set compression=lz4 mypool), а
> > вот дедупликация... я за несколько лет так и не смог увидеть в домашних
> > условиях где бы это могло помочь.
>
>Хотелось бы понять, точно или нет. У меня, например, одни и те же
>фотографии в некотором количестве хранятся в архиве оригиналов (на
>сервере), у жены на виндовом компе, где она их отбирает и обрабатывает
>(обрабатывает не больше трети), откуда попадают в бэкап на тот же
>сервер, у меня на ноуте, и тоже в бэкап, и на планшете, откуда, опять же
>в бэкап. Суммарный объем копий на компе жены измеряется не меньше чем
>десятками гигабайт. По идее, не очень много, но интересно было бы
>поэкспериментировать. Если бы много, то от 2 до 4 копий - это уже вполне
>повод для дедупликации, но вроде на фоне остального не шибко дофига.

С дедупликацией не хватит 8-ми GB. А без неё работать точно будет.
"Выжмет" ли оно всё из дисков -- надо смотреть, но мне кажется что без
проблем, если речь о перегонке/хранении фотографий.

>Там поблочные дельты хранятся или пофайловые? Грубо, если файл
>переименован, снапшот будет отличаться только инодом, или блоки тоже
>отделит?

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

>А кстати, раз в ZFS можно на ходу включить и выключить дедупликацию:
>возможна ли эпизодическая ручная дедупликация? Т.е. чтобы включил, она
>отработала, выключил (а то памяти мало для ее постоянной работы), а
>результат остался?

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

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

[Artem Chuprina]

artiom -> debian-russian@lists.debian.org  @ Sun, 25 Jun 2017 14:04:54 +0300:

 >>> Внезапного выключения питания не бывает, если не сдохли аккумуляторы в ИБП.
 >> 
 >> Бывает внезапная поломка backplane, контроллера, блока питания,
 >> материнской платы, итд.
 >> 
 > Не поможет тогда контроллер.
 > К тому же, это для каких-то очень критичных систем.
 > А там, как правило, данные по нескольким разным машинам/датацентрам
 > реплицируются, и проблема тоже не сильно актуальна.

А еще бывает выдергивание кабеля между ИБП и компьютером, и нечанное
нажатие на аппаратный тумблер питания на БП... Как правило, не в режиме
"совсем нечаянно", а в режиме "коробку перепутали".

Re: ZFS

[Artem Chuprina]

Sergey Matveev -> debian-russian@lists.debian.org  @ Sat, 24 Jun 2017 23:10:40 
+0300:

 > *** Artem Chuprina  [2017-06-24 22:49]:
 >>Я правильно понимаю, что если я, допустим, хочу хранить
 >>бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки ставить
 >>на нормальный раздел, а не на zfs же? А zfs разворачивать поверх второго
 >>раздела?
 >>
 >>А если я, допустим, хочу рейд на нескольких дисках, то поделить каждый
 >>так же на два раздела, на первых сделать raid1 с системой, а на вторых
 >>собирать raidz?
 >>
 >>Потому что систему на zfs я если и водружу, то в случае сбоя хрен я к
 >>файловой системе штатными средствами бутовой флешки доберусь?

 > Не знаю как в GNU/Linux, но не могу представить в чём может быть
 > проблема или подстава достучаться до ФС с бутовой флешки? Загрузились на
 > "LiveCD" с флешки, сделали zpool import mypool и всё.

Проблема в том, что на легко добываемом LiveCD или rescue флешке
дистрибутива модулей zfs нет. И zfs-fuse тоже нет. Т.е. надо _заранее_
озаботиться наличием live USB с zfs-fuse и zfs-utils.

 > Ну ok, как правило
 > оно захочет подмонтировать сразу же и поэтому перед этим надо указать
 > другую директорию монтирования. Я так делал много раз, просто указывая
 > какой-нибудь /tmp/mypool. Я не понял в чём проблемы держать систему на
 > ZFS. Там это очень кстати бы было если например делается какой-нибудь
 > dist-upgrade и хочется откатиться до начального состояния в случае
 > проблем.

В zfs есть понятие "переключиться на такой-то снапшот" в смысле сделать
так, что в качестве основного состояния FS будет подключен он? И оно это
запомнит через перезагрузку? Если так, то это интересно...

 >>И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта суммой
 >>из всего этого уже забито, я собираюсь ставить 4-терабайтник,
 >>вероятно. На работе имеется в виду держать зеркало из пары
 >>4-терабайтников.
 >>
 >>В обоих случаях супербыстрый доступ не требуется, но и суровых тормозов
 >>быть не должно. 
 >>
 >>Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
 >>более-менее комфортно? А если я захочу дедупликацию включить?  (Кстати,
 >>ее можно включить/выключить на ходу, или это надо делать в момент
 >>создания FS?)

 > 8 гигабайт точно хватит, а вот с 4-мя терзают сомнения. А вот если
 > хочется включить дедупликацию, то, личного опыта нет, но говорят что
 > нужно примерно 5 гигабайт RAM на каждый терабайт данных. То есть в
 > случае с 4 TB дисками, лучше бы иметь более 20 гигабайт. Дедупликацию
 > можно включить на уже работающей системе, когда угодно, как и выключить.
 > А точно вам нужна дедупликация? Вот например прозрачное сжатие LZ4 штука
 > я считаю почти всегда не помешающая (zfs set compression=lz4 mypool), а
 > вот дедупликация... я за несколько лет так и не смог увидеть в домашних
 > условиях где бы это могло помочь.

Хотелось бы понять, точно или нет. У меня, например, одни и те же
фотографии в некотором количестве хранятся в архиве оригиналов (на
сервере), у жены на виндовом компе, где она их отбирает и обрабатывает
(обрабатывает не больше трети), откуда попадают в бэкап на тот же
сервер, у меня на ноуте, и тоже в бэкап, и на планшете, откуда, опять же
в бэкап. Суммарный объем копий на компе жены измеряется не меньше чем
десятками гигабайт. По идее, не очень много, но интересно было бы
поэкспериментировать. Если бы много, то от 2 до 4 копий - это уже вполне
повод для дедупликации, но вроде на фоне остального не шибко дофига.

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

Там поблочные дельты хранятся или пофайловые? Грубо, если файл
переименован, снапшот будет отличаться только инодом, или блоки тоже
отделит?

 > Где-то я чуть ли не в официальных мануалах Sun-а (Oracle?) видел что
 > зачастую правильное использование clone-ов (snapshot и прочего)
 > решает большинство проблем с избыточностью, где люди думают о
 > дедупликации. Хотя если это какой-нибудь там хостинг картиночек, где
 > одни и те же кошечки тысячами пользователей заливаются, то там
 > поможет. В ZFS есть команда zdb -S mypool которая "эмулирует"
 > дедупликацию и показывает поможет ли она или нет. Буквально вчера на
 > одном из разделов её делал у себя (подумал что может пора?):

 > # zdb -S storage
 > Simulated DDT histogram:

 > bucket  allocated   referenced
 > __   __   __
 > refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
 > --   --   -   -   -   --   -   -   -
 >  18.87M   1.11T   1.10T   1.10T8.87M   1.11T   1.10T   1.10T
 >  26.31K807M782M782M13.0K   1.63G   1.57G   1.57G
 >  4  250   31.2M   27.2M   27.2M1.08K138M120M120M
 

Re: ZFS

[Sergey Matveev]

*** artiom  [2017-06-25 14:06]:
>> Бывает внезапная поломка backplane, контроллера, блока питания,
>> материнской платы, итд.
>> 
>Не поможет тогда контроллер.

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

>К тому же, это для каких-то очень критичных систем.
>А там, как правило, данные по нескольким разным машинам/датацентрам
>реплицируются, и проблема тоже не сильно актуальна.

Проблема того что у вас есть возможность получить неконсистентные
данные, испорченные. По моему это очень критично, независимо от задач. У
нас же ЭВМ, куча миллиардов инструкций, гигабайты хранилищ, а данные
могут быть потеряны... не порядок это.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

[Sergey Matveev]

*** artiom  [2017-06-25 14:04]:
>/var не на отдельном разделе?

Это вообще отдельная директория (не /var) на зашифрованном разделе.

>Он упаковку мелких файлов в один блок, как reiserfs, умеет?

Он может динамически менять размер блока (как конкретно -- не знаю). Но
нет, в один блок засунуть несколько "данных" не может (как ещё кстати и
XFS умеет).

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

Да, на системе для которой место не было зарезервивано он скажет что
места не осталось. Тут резервируется место для filesystem, но свободное
место для проблемы фрагментации должно быть не на filesystem, а на
pool-е. Pool может содержать несколько filesystem (всё это термины в
контексте ZFS). Поэтому это место на пуле будет использоваться само
собой, оно не прикасаемое. reservation это просто квота для отдельной
filesystem (грубо говоря, директории).

>А этот RAIDZ (пока не почитал про него), он и есть срайп с контрольными
>суммами?

Грубо говоря, да. Аналогично RAID5/6.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

[artiom]

25.06.2017 14:00, Sergey Matveev пишет:
> *** artiom  [2017-06-25 13:53]:
>> А если я хочу часть памяти под другие нужды?
>> У неё квоты есть?
> 
> Через sysctl можно ограничить максимальный размер ARC-а (кэша ZFS).
> Например для PostgreSQL на ZFS как-раз и дают такой совет, чтобы ZFS не
> отхапал себе лишнего, более полезного для СУБД.
> 
О, это хорошо.

Re: ZFS

[artiom]

25.06.2017 14:01, Sergey Matveev пишет:
> *** artiom  [2017-06-25 13:49]:
>> Внезапного выключения питания не бывает, если не сдохли аккумуляторы в ИБП.
> 
> Бывает внезапная поломка backplane, контроллера, блока питания,
> материнской платы, итд.
> 
Не поможет тогда контроллер.
К тому же, это для каких-то очень критичных систем.
А там, как правило, данные по нескольким разным машинам/датацентрам
реплицируются, и проблема тоже не сильно актуальна.

Re: ZFS

[artiom]

25.06.2017 13:57, Sergey Matveev пишет:
> *** artiom  [2017-06-25 13:47]:
>> 68% фрагментации, вы это серьёзно?
> 
> Я сам не знаю как это интерпретировать. Возможно это связано как-то и с
> размером записи (recordsize) по-умолчанию. На этом разделе в основном
> только почта в maildir формате.
/var не на отдельном разделе?
Он упаковку мелких файлов в один блок, как reiserfs, умеет?

> recordsize стоит в 128 KiB. Видимо то,
> что каждое сообщение по-умолчанию пихается в такой большой блок и
> приводит к таким цифрам. Ибо уж после zfs recv команды фрагментация
> должна быть нулевая, так как поток после zfs send полностью
> сериализован, но на деле он так не показывает. Всё же на это разделе
> фрагментация как мы (пользователи не ZFS) её понимаем вообще нулевая, но
> из особенностей только тысячи тысячи маленьких файлов и recordsize=128KiB.
> 
В любом случае, пока у меня ext4 на обычных машинах, меня всё устраивает.
На хранилище наверное запилю ZFS.
Буду под неё и железо смотреть.

>> Я понимаю, но это значит, что надо за процентом заполнения следить.
> 
> Либо сделать раздел у которого зарезервировать нужное кол-во места.
> Есть zfs set reservation команда.
> 
Ok. Но он его будет использовать для своих нужд?
И что будет, когда квота выйдет, просто скажет, что места не осталось?

>> Кстати, а как оно распределяет большой файл по дискам в пуле (в разных
>> режимах)?
> 
> stripe-ом по возможности старается, чтобы распараллелить чтение/запись,
> как и RAID. Если зеркало, то само собой чтобы копии на двух дисках.
> 
А этот RAIDZ (пока не почитал про него), он и есть срайп с контрольными
суммами?

Re: ZFS

[Sergey Matveev]

*** artiom  [2017-06-25 13:49]:
>Внезапного выключения питания не бывает, если не сдохли аккумуляторы в ИБП.

Бывает внезапная поломка backplane, контроллера, блока питания,
материнской платы, итд.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

[Sergey Matveev]

*** artiom  [2017-06-25 13:53]:
>А если я хочу часть памяти под другие нужды?
>У неё квоты есть?

Через sysctl можно ограничить максимальный размер ARC-а (кэша ZFS).
Например для PostgreSQL на ZFS как-раз и дают такой совет, чтобы ZFS не
отхапал себе лишнего, более полезного для СУБД.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

[artiom]

25.06.2017 12:01, Vasiliy P. Melnik пишет:
> Если мы говорим о системе из трех дисков и говорим о дебиан 9 - я
> проверял, граб наконец-то научился бутить кернел из лвм-раздела.
Так уж сколько лет назад...
У меня комп стационарный с 11-го года.
И там всё с LVM грузится.

> Я бы поспуил следующим образом
> 1) выделить на каждом диске раздел в начала 80 гигов
> 2) создать второй раздел
> 3) создать рейд1 и в него включить этих три раздела.
Зачем?
Ради защиты от падения ОС?
А выделить под ОС, например SSD?

> 4) поверх рейда создать лвм-раздел
> 5) поставить систему на этот лвм
> 6) установить зфс модули в систему
> 7) из оставшихся трех раздел собрать пул raidz
> 
> 
> 24 июня 2017 г., 15:01 пользователь Artem Chuprina  > написал:
> 
> Граждане, раз уж пошла такая пьянка.
> 
> Я правильно понимаю, что если я, допустим, хочу хранить
> бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки ставить
> на нормальный раздел, а не на zfs же? А zfs разворачивать поверх второго
> раздела?
> 
> А если я, допустим, хочу рейд на нескольких дисках, то поделить каждый
> так же на два раздела, на первых сделать raid1 с системой, а на вторых
> собирать raidz?
> 
> Потому что систему на zfs я если и водружу, то в случае сбоя хрен я к
> файловой системе штатными средствами бутовой флешки доберусь?
> 
> Это я задумываюсь про апгрейд двух серверов - домашнего, который он же
> файлообменник, и бэкап-сервера на работе. Дома в норме один диск, на
> работе - рейд.
> 
> И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта суммой
> из всего этого уже забито, я собираюсь ставить 4-терабайтник,
> вероятно. На работе имеется в виду держать зеркало из пары
> 4-терабайтников.
> 
> В обоих случаях супербыстрый доступ не требуется, но и суровых тормозов
> быть не должно.
> 
> Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
> более-менее комфортно? А если я захочу дедупликацию включить?  (Кстати,
> ее можно включить/выключить на ходу, или это надо делать в момент
> создания FS?)
> 
> 

Re: ZFS

[Sergey Matveev]

*** artiom  [2017-06-25 13:47]:
>68% фрагментации, вы это серьёзно?

Я сам не знаю как это интерпретировать. Возможно это связано как-то и с
размером записи (recordsize) по-умолчанию. На этом разделе в основном
только почта в maildir формате. recordsize стоит в 128 KiB. Видимо то,
что каждое сообщение по-умолчанию пихается в такой большой блок и
приводит к таким цифрам. Ибо уж после zfs recv команды фрагментация
должна быть нулевая, так как поток после zfs send полностью
сериализован, но на деле он так не показывает. Всё же на это разделе
фрагментация как мы (пользователи не ZFS) её понимаем вообще нулевая, но
из особенностей только тысячи тысячи маленьких файлов и recordsize=128KiB.

>Я понимаю, но это значит, что надо за процентом заполнения следить.

Либо сделать раздел у которого зарезервировать нужное кол-во места.
Есть zfs set reservation команда.

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

stripe-ом по возможности старается, чтобы распараллелить чтение/запись,
как и RAID. Если зеркало, то само собой чтобы копии на двух дисках.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

[artiom]

25.06.2017 12:30, Sergey Matveev пишет:
> *** Vasiliy P. Melnik  [2017-06-25 12:11]:
>> действительно, чем больше - тем лучше, потому как сожрет все, что есть, но
>> мало памяти - просто медленнее работает. Никаких крашей это не вызывает
> 
> Тут ещё особенность самой фри очень любить память и своп. Linux будет
> свопаться (по-умолчанию) только если реально что-то начинает не
> умещаться в память и её никак не освободить.
Нет, он свопаться будет, в соответствии с настройками swapiness (там
несколько параметров).
По дефолту, грубо, он будет свопать, когда оперативки остаётся 10 или 20 %.
Но настроить возможно и так.
У меня как-раз свопается, когда не умещается что-то в памяти, потому что
своп на SSD и его не очень хорошо часто перезаписывать.

> А FreeBSD по-умолчанию
> просто ради обычного кэша ФС (даже без ZFS) может выгрузить процесс в
> своп, потому-что он давно не просыпался (какой-нибудь демон надолго
> уснувший и ничего не делающий).
>
Так наверняка всё настраивается.

> А так в ARC кэше ZFS есть MRU (most recently used), MFU (most frequently
> used) участки кэша. Любое чтение/запись данных их всегда поместят в MRU
> раздел и поэтому память всегда будет вся забита хоть чем-то.
> 
>> З.Ы.повелся на бтрфс - ну типа линукс, зачем у него тянуть инородное, есть
>> же родное. Очень не доволен, не нравится скорость работы. Сравнить пока не
>> с чем - 7 терабайт бекапов тяжело перекинуть куда-то, чтобы перекинуть на
>> зфс
> 
> Btrfs не умеет аналогов RAID5/RAID6 (в ZFS RAIDZ1/2/3), не умеет
> выделенных дисков для кэша второго уровня (flashcache аналог Linux) --
> что говорит что он не для серьёзного enterprise. Ну и вместо
> криптографических хэшей используется CRC32C, насколько вижу по
> Wikipedia... лично по мне, так это основной аргумент почему я даже не
> смотрел бы в их сторону. Доверять целостность не криптографическим хэшам
> я не могу.
> 
Он ФС а не замена всему, как ZFS.

Re: ZFS

[artiom]

25.06.2017 12:09, Vasiliy P. Melnik пишет:
> Чтобы никого не вводить в заблуждение - все мои выкладки по зфс-у из
> фри, пользуюсь уже давно, еще с 8-рки насколько помню. Как диски стал в
> сервер ставить больше 1 ТБ
> 
> про память:
> действительно, чем больше - тем лучше, потому как сожрет все, что есть,
> но мало памяти - просто медленнее работает. Никаких крашей это не вызывает
> 
А если я хочу часть памяти под другие нужды?
Раздачу там чего-нибудь организовать, интерфейс и т.п..
У неё квоты есть?

Re: ZFS

[artiom]

25.06.2017 02:29, Sergey Matveev пишет:
> *** artiom  [2017-06-25 00:21]:
>> У вас прям по ZFS сплошные плюсы.
> 
> Кстати, забыл отметить важное (если не важнейшее) отличие ZFS массивов
> от RAID-ов: проблема write-hole-ов. Например у вас RAID5 и чтобы
> консистентность данных была в порядке, то при записи вы обязаны сделать
> атомарную запись всех stripe-ов на все диски. А сделать это атомарно на
> три (или более) аппаратных диска просто невозможно. Внезапное выключение
> питания запросто приведёт к тому что на каком-то диске что-то
> недозаписано. И встаёт проблема: кому доверять и как понять на ком
> недочёт. Решают аппаратные контроллеры её за счёт использования памяти,
> подпитываемой батарейкой (или SSD в контроллере), где хранится
> информация о записанных данных. При восстановлении питания, он тогда
> сможет понять что надо дозаписать. Но это хорошие дорогие контроллеры.
> Программно так не сделать и при внезапном выключении питания вы сильно
> рискуете реально потерять данные в stripe массива. С RAIDZ всё что
> увидит ФС -- атомарно. Или она увидит обновлённый корень дерева хэшей
> или нет. При пропаже питания вы безусловно рискуете потерять то что не
> смогло быть чисто физически записано на диск, но никакого нарушения
> целостности. То есть фича дорогих аппаратных контроллеров с батарейкой
> или SSD на боту -- бесплатно в софте.
> 
Внезапного выключения питания не бывает, если не сдохли аккумуляторы в ИБП.

Re: ZFS

[artiom]

25.06.2017 01:50, Sergey Matveev пишет:
> *** artiom  [2017-06-25 01:36]:
>> Потому и фрагментация низкая: я с 11-го года комп не дефрагментировал,
>> посмотрел e4defrag-ом, меньше двух процентов.
> 
> На моём ноутбуке сейчас :-):
> 
> # zpool list
> NAME SIZE  ALLOC   FREE  EXPANDSZ   FRAGCAP  DEDUP  HEALTH
> secure  1008M   149M   859M -68%14%  1.00x  ONLINE
> stcvol  15.9G  1.83G  14.0G -42%11%  1.00x  ONLINE
> zroot 89G  32.3G  56.7G -44%36%  1.00x  ONLINE
> 
68% фрагментации, вы это серьёзно?

>> Так всё-таки RAM или дисковое пространство свободное больше требуется?
> 
> И то и другое :-). Если высокая фрагментация (мало свободного места), то
> вы всё-равно упрётесь в лавинообразный рост IO на диск и память тут не
> поможет. ZFS всегда пишет данные в самое большое свободное место на
> диске (самую большу "дырку"). Вообще штатно считается что в большинстве
> случаев фрагментация не является проблемой на практике в большинстве
> режимов использования/нагрузки. Собственно лично я с фрагментацией
> сталкивался только на дисках куда сбрасываю бэкапы, где я делал это
> впритык, до последнего гигабайта.
> 
Я понимаю, но это значит, что надо за процентом заполнения следить.

>>> Вот это можно сказать и недостаток. Её нет. Есть хаки в виде
>>> resilvering-а, то бишь rebuild-а на диски, при котором на них будет
>>> дефрагментированный образ создан.
>> Условно: mv всего на другой раздел?
> 
> Да, можно и так. Суть одна. Заставить прочитать и записать в другое
> место. Чтение пускай не очень быстрое (из-за фрагментированного файла),
> но запись уже более быстрая (менее разряженно).
> 
>> А нет a-la e4defrag?
> 
> Нету ни этого, ни xfs_fsr. Только вот хаки. Которые метаинформацию никак
> не трогают. Повторюсь: проблема фрагментации зависит от режимов
> нагрузки. Но достаточно, в большинстве случаев, просто иметь место про
> запас и не париться.
> 
Это печально.

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

Re: ZFS

[Vasiliy P. Melnik]

> Btrfs не умеет аналогов RAID5/RAID6 (в ZFS RAIDZ1/2/3)


Точно - уже забыл, давно делал.
делал рейд5 на mdadm , а на бтрфс-е включил компрессию.

Re: ZFS

[Sergey Matveev]

*** Vasiliy P. Melnik  [2017-06-25 12:11]:
>действительно, чем больше - тем лучше, потому как сожрет все, что есть, но
>мало памяти - просто медленнее работает. Никаких крашей это не вызывает

Тут ещё особенность самой фри очень любить память и своп. Linux будет
свопаться (по-умолчанию) только если реально что-то начинает не
умещаться в память и её никак не освободить. А FreeBSD по-умолчанию
просто ради обычного кэша ФС (даже без ZFS) может выгрузить процесс в
своп, потому-что он давно не просыпался (какой-нибудь демон надолго
уснувший и ничего не делающий).

А так в ARC кэше ZFS есть MRU (most recently used), MFU (most frequently
used) участки кэша. Любое чтение/запись данных их всегда поместят в MRU
раздел и поэтому память всегда будет вся забита хоть чем-то.

>З.Ы.повелся на бтрфс - ну типа линукс, зачем у него тянуть инородное, есть
>же родное. Очень не доволен, не нравится скорость работы. Сравнить пока не
>с чем - 7 терабайт бекапов тяжело перекинуть куда-то, чтобы перекинуть на
>зфс

Btrfs не умеет аналогов RAID5/RAID6 (в ZFS RAIDZ1/2/3), не умеет
выделенных дисков для кэша второго уровня (flashcache аналог Linux) --
что говорит что он не для серьёзного enterprise. Ну и вместо
криптографических хэшей используется CRC32C, насколько вижу по
Wikipedia... лично по мне, так это основной аргумент почему я даже не
смотрел бы в их сторону. Доверять целостность не криптографическим хэшам
я не могу.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

[Sergey Matveev]

*** Igor Savlook  [2017-06-25 11:56]:
>15 минут более чем хватит, следуя твоей логике также может отказать и
>аппаратный raid что тоже повлечет за собой крах массива и упаси чтобы
>этот аппаратный raid был vendor-lock

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

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

[Vasiliy P. Melnik]

е знаю правда или нет, но когда появился стандарт сата и первые диски, sun
приехал на выставку и анонсировал свои системы хранения данных, построенные
на solaris-e и zfs, ну и на дисках сата. Стандарт считался сырым, глючным и
ни один нормальный админ не готов был доверять ему диски.

Все были одеты в футболки с надписью - мы любим сата.

Я использую зфс с фри 8.0, когда он там только появился. Используются
сервера на обычном десктопном железе, их больше десятка, на примерно 25%
отсутсвуют упс-ы, установлены могут быть где угодно - ни одного в
гермозоне. Проблема была один раз - виновата была мертвая планка памяти.

25 июня 2017 г., 2:29 пользователь Sergey Matveev 
написал:

> *** artiom  [2017-06-25 00:21]:
> >У вас прям по ZFS сплошные плюсы.
>
> Кстати, забыл отметить важное (если не важнейшее) отличие ZFS массивов
> от RAID-ов: проблема write-hole-ов. Например у вас RAID5 и чтобы
> консистентность данных была в порядке, то при записи вы обязаны сделать
> атомарную запись всех stripe-ов на все диски. А сделать это атомарно на
> три (или более) аппаратных диска просто невозможно. Внезапное выключение
> питания запросто приведёт к тому что на каком-то диске что-то
> недозаписано. И встаёт проблема: кому доверять и как понять на ком
> недочёт. Решают аппаратные контроллеры её за счёт использования памяти,
> подпитываемой батарейкой (или SSD в контроллере), где хранится
> информация о записанных данных. При восстановлении питания, он тогда
> сможет понять что надо дозаписать. Но это хорошие дорогие контроллеры.
> Программно так не сделать и при внезапном выключении питания вы сильно
> рискуете реально потерять данные в stripe массива. С RAIDZ всё что
> увидит ФС -- атомарно. Или она увидит обновлённый корень дерева хэшей
> или нет. При пропаже питания вы безусловно рискуете потерять то что не
> смогло быть чисто физически записано на диск, но никакого нарушения
> целостности. То есть фича дорогих аппаратных контроллеров с батарейкой
> или SSD на боту -- бесплатно в софте.
>
> --
> Sergey Matveev (http://www.stargrave.org/)
> OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF
>
>

Re: ZFS

[Vasiliy P. Melnik]

Чтобы никого не вводить в заблуждение - все мои выкладки по зфс-у из фри,
пользуюсь уже давно, еще с 8-рки насколько помню. Как диски стал в сервер
ставить больше 1 ТБ

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

З.Ы.повелся на бтрфс - ну типа линукс, зачем у него тянуть инородное, есть
же родное. Очень не доволен, не нравится скорость работы. Сравнить пока не
с чем - 7 терабайт бекапов тяжело перекинуть куда-то, чтобы перекинуть на
зфс

Re: ZFS

[Vasiliy P. Melnik]

Если мы говорим о системе из трех дисков и говорим о дебиан 9 - я проверял,
граб наконец-то научился бутить кернел из лвм-раздела. Я бы поспуил
следующим образом
1) выделить на каждом диске раздел в начала 80 гигов
2) создать второй раздел
3) создать рейд1 и в него включить этих три раздела.
4) поверх рейда создать лвм-раздел
5) поставить систему на этот лвм
6) установить зфс модули в систему
7) из оставшихся трех раздел собрать пул raidz


24 июня 2017 г., 15:01 пользователь Artem Chuprina 
написал:

> Граждане, раз уж пошла такая пьянка.
>
> Я правильно понимаю, что если я, допустим, хочу хранить
> бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки ставить
> на нормальный раздел, а не на zfs же? А zfs разворачивать поверх второго
> раздела?
>
> А если я, допустим, хочу рейд на нескольких дисках, то поделить каждый
> так же на два раздела, на первых сделать raid1 с системой, а на вторых
> собирать raidz?
>
> Потому что систему на zfs я если и водружу, то в случае сбоя хрен я к
> файловой системе штатными средствами бутовой флешки доберусь?
>
> Это я задумываюсь про апгрейд двух серверов - домашнего, который он же
> файлообменник, и бэкап-сервера на работе. Дома в норме один диск, на
> работе - рейд.
>
> И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта суммой
> из всего этого уже забито, я собираюсь ставить 4-терабайтник,
> вероятно. На работе имеется в виду держать зеркало из пары
> 4-терабайтников.
>
> В обоих случаях супербыстрый доступ не требуется, но и суровых тормозов
> быть не должно.
>
> Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
> более-менее комфортно? А если я захочу дедупликацию включить?  (Кстати,
> ее можно включить/выключить на ходу, или это надо делать в момент
> создания FS?)
>
>

Re: ZFS

[Igor Savlook]

On Sun, 2017-06-25 at 11:35 +0300, Sergey Matveev wrote:
> *** Igor Savlook  [2017-06-25 03:08]:
> > Вроде как UPS может помочь с этой проблемой.
> 
> На сколько-то минут. Кроме того, внезапный отказ может произойти в
> компьютере (мать, контроллер, итд).
> 
15 минут более чем хватит, следуя твоей логике также может отказать и
аппаратный raid что тоже повлечет за собой крах массива и упаси чтобы
этот аппаратный raid был vendor-lock

Re: ZFS

[Sergey Matveev]

*** Igor Savlook  [2017-06-25 03:08]:
>Вроде как UPS может помочь с этой проблемой.

На сколько-то минут. Кроме того, внезапный отказ может произойти в
компьютере (мать, контроллер, итд).

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

[Igor Savlook]

On Sun, 2017-06-25 at 02:29 +0300, Sergey Matveev wrote:
> *** artiom  [2017-06-25 00:21]:
> > У вас прям по ZFS сплошные плюсы.
> 
> Кстати, забыл отметить важное (если не важнейшее) отличие ZFS
> массивов
> от RAID-ов: проблема write-hole-ов. Например у вас RAID5 и чтобы
> консистентность данных была в порядке, то при записи вы обязаны
> сделать
> атомарную запись всех stripe-ов на все диски. А сделать это атомарно
> на
> три (или более) аппаратных диска просто невозможно. Внезапное
> выключение
> питания запросто приведёт к тому что на каком-то диске что-то
> недозаписано. И встаёт проблема: кому доверять и как понять на ком
> недочёт. Решают аппаратные контроллеры её за счёт использования
> памяти,
> подпитываемой батарейкой (или SSD в контроллере), где хранится
> информация о записанных данных. При восстановлении питания, он тогда
> сможет понять что надо дозаписать. Но это хорошие дорогие
> контроллеры.
> Программно так не сделать и при внезапном выключении питания вы
> сильно
> рискуете реально потерять данные в stripe массива. С RAIDZ всё что
> увидит ФС -- атомарно. Или она увидит обновлённый корень дерева хэшей
> или нет. При пропаже питания вы безусловно рискуете потерять то что
> не
> смогло быть чисто физически записано на диск, но никакого нарушения
> целостности. То есть фича дорогих аппаратных контроллеров с
> батарейкой
> или SSD на боту -- бесплатно в софте.
> 
Вроде как UPS может помочь с этой проблемой.

Re: ZFS

[Sergey Matveev]

*** artiom  [2017-06-25 00:21]:
>У вас прям по ZFS сплошные плюсы.

Кстати, забыл отметить важное (если не важнейшее) отличие ZFS массивов
от RAID-ов: проблема write-hole-ов. Например у вас RAID5 и чтобы
консистентность данных была в порядке, то при записи вы обязаны сделать
атомарную запись всех stripe-ов на все диски. А сделать это атомарно на
три (или более) аппаратных диска просто невозможно. Внезапное выключение
питания запросто приведёт к тому что на каком-то диске что-то
недозаписано. И встаёт проблема: кому доверять и как понять на ком
недочёт. Решают аппаратные контроллеры её за счёт использования памяти,
подпитываемой батарейкой (или SSD в контроллере), где хранится
информация о записанных данных. При восстановлении питания, он тогда
сможет понять что надо дозаписать. Но это хорошие дорогие контроллеры.
Программно так не сделать и при внезапном выключении питания вы сильно
рискуете реально потерять данные в stripe массива. С RAIDZ всё что
увидит ФС -- атомарно. Или она увидит обновлённый корень дерева хэшей
или нет. При пропаже питания вы безусловно рискуете потерять то что не
смогло быть чисто физически записано на диск, но никакого нарушения
целостности. То есть фича дорогих аппаратных контроллеров с батарейкой
или SSD на боту -- бесплатно в софте.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

[Sergey Matveev]

*** artiom  [2017-06-25 01:36]:
>Потому и фрагментация низкая: я с 11-го года комп не дефрагментировал,
>посмотрел e4defrag-ом, меньше двух процентов.

На моём ноутбуке сейчас :-):

# zpool list
NAME SIZE  ALLOC   FREE  EXPANDSZ   FRAGCAP  DEDUP  HEALTH
secure  1008M   149M   859M -68%14%  1.00x  ONLINE
stcvol  15.9G  1.83G  14.0G -42%11%  1.00x  ONLINE
zroot 89G  32.3G  56.7G -44%36%  1.00x  ONLINE

>Так всё-таки RAM или дисковое пространство свободное больше требуется?

И то и другое :-). Если высокая фрагментация (мало свободного места), то
вы всё-равно упрётесь в лавинообразный рост IO на диск и память тут не
поможет. ZFS всегда пишет данные в самое большое свободное место на
диске (самую большу "дырку"). Вообще штатно считается что в большинстве
случаев фрагментация не является проблемой на практике в большинстве
режимов использования/нагрузки. Собственно лично я с фрагментацией
сталкивался только на дисках куда сбрасываю бэкапы, где я делал это
впритык, до последнего гигабайта.

>> Вот это можно сказать и недостаток. Её нет. Есть хаки в виде
>> resilvering-а, то бишь rebuild-а на диски, при котором на них будет
>> дефрагментированный образ создан.
>Условно: mv всего на другой раздел?

Да, можно и так. Суть одна. Заставить прочитать и записать в другое
место. Чтение пускай не очень быстрое (из-за фрагментированного файла),
но запись уже более быстрая (менее разряженно).

>А нет a-la e4defrag?

Нету ни этого, ни xfs_fsr. Только вот хаки. Которые метаинформацию никак
не трогают. Повторюсь: проблема фрагментации зависит от режимов
нагрузки. Но достаточно, в большинстве случаев, просто иметь место про
запас и не париться.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

[artiom]

25.06.2017 01:06, Sergey Matveev пишет:
> *** artiom  [2017-06-25 00:54]:
>> Вы хотите сказать, что она жрёт 20% места под метаданные?!
>> Или что она просто начинает сильно фрагментироваться, при заполнении?
> 
> Из-за её copy-on-write природы она начинает сильно фрагментироваться,
> верно. Любое изменение данных это создание полной копии и блока данных и
> сопутствующей метаинформации. Само собой перед записью они агрегируются,
> но всё-равно при записи большого файла на диск он никогда не будет
> размещён последовательно: каждые 1-5 секунд ZFS делает checkpoint-ы --
> то есть на диске идут сколько-то блоков данных файла, потом всякая
> метаинформация, снова блоки, потом метаинформация. Причём каждый набор
> метаинформации создаваемый в последующих 1-5 секунд делает неактуальным
> предыдущую. То есть она потенциально становится свободным местом.
> Например *X*FS реально абсолютно последовательно может разместить файл
> на диске
Потому и фрагментация низкая: я с 11-го года комп не дефрагментировал,
посмотрел e4defrag-ом, меньше двух процентов.

> а ZFS нет -- поэтому и нужно много памяти под кэш чтобы
> сгладить всё это, не создавая огромный IO на диск.
> 
Так всё-таки RAM или дисковое пространство свободное больше требуется?

> Но вот зато при неправильной конфигурации RAIDZ, в которой выбрать
> определённое количество дисков и определённый размер блока (recordsize),
> то можно, фактически, просто так потерять 50% места буквально в пустую.
> Вот тут есть тема про это: 
> https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz
Почитаю, но пока начал с педивикии.

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

>> Во втором случае, ведь должна быть онлайн дефрагментация...
> 
> Вот это можно сказать и недостаток. Её нет. Есть хаки в виде
> resilvering-а, то бишь rebuild-а на диски, при котором на них будет
> дефрагментированный образ создан.
Условно: mv всего на другой раздел?

> Можно сделать полный zfs send и
> восстановление ФС zfs recv-ом, но это потребует остановки ФС, что не
> всегда допустимо и возможно. Есть хаки в виде просто копирования файла:
> cp file file.tmp && mv file.tmp file, чтобы сделать его
> дефрагментированным, если, например, он был медленно записан (то бишь,
> из-за частых checkpoint-ов, сильно разряжён). Где-то на форумах они
> говорят что создание online дефрагментации это жутко нетривиальная вещь,
> требующая чуть ли не переписывания всего кода, ибо везде всё одна
> крипта, деревья Меркле, checkoint, итд, итд -- сложно это сделать так,
> чтобы гарантировать "железную" надёжность и поэтому не будут делать.
> 
А нет a-la e4defrag?

Re: ZFS

[Sergey Matveev]

*** artiom  [2017-06-25 00:54]:
>Вы хотите сказать, что она жрёт 20% места под метаданные?!
>Или что она просто начинает сильно фрагментироваться, при заполнении?

Из-за её copy-on-write природы она начинает сильно фрагментироваться,
верно. Любое изменение данных это создание полной копии и блока данных и
сопутствующей метаинформации. Само собой перед записью они агрегируются,
но всё-равно при записи большого файла на диск он никогда не будет
размещён последовательно: каждые 1-5 секунд ZFS делает checkpoint-ы --
то есть на диске идут сколько-то блоков данных файла, потом всякая
метаинформация, снова блоки, потом метаинформация. Причём каждый набор
метаинформации создаваемый в последующих 1-5 секунд делает неактуальным
предыдущую. То есть она потенциально становится свободным местом.
Например *X*FS реально абсолютно последовательно может разместить файл
на диске, а ZFS нет -- поэтому и нужно много памяти под кэш чтобы
сгладить всё это, не создавая огромный IO на диск.

Но вот зато при неправильной конфигурации RAIDZ, в которой выбрать
определённое количество дисков и определённый размер блока (recordsize),
то можно, фактически, просто так потерять 50% места буквально в пустую.
Вот тут есть тема про это: 
https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz
RAIDZ сделан так, что добавляет чётность, но кол-во получившихся блоков
для данных+parity должны быть кратны чему-то там и поэтому там будет
создан блок чисто для padding-а, для выравнивания некоего, не несущего
полезных данных. Статья эта подчёркивает что в RAIDZ на parity всё же
будет больше затрачено места чем в аналогичных уровнях RAID, как
правило.

>Во втором случае, ведь должна быть онлайн дефрагментация...

Вот это можно сказать и недостаток. Её нет. Есть хаки в виде
resilvering-а, то бишь rebuild-а на диски, при котором на них будет
дефрагментированный образ создан. Можно сделать полный zfs send и
восстановление ФС zfs recv-ом, но это потребует остановки ФС, что не
всегда допустимо и возможно. Есть хаки в виде просто копирования файла:
cp file file.tmp && mv file.tmp file, чтобы сделать его
дефрагментированным, если, например, он был медленно записан (то бишь,
из-за частых checkpoint-ов, сильно разряжён). Где-то на форумах они
говорят что создание online дефрагментации это жутко нетривиальная вещь,
требующая чуть ли не переписывания всего кода, ибо везде всё одна
крипта, деревья Меркле, checkoint, итд, итд -- сложно это сделать так,
чтобы гарантировать "железную" надёжность и поэтому не будут делать.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

[artiom]

> Дорогая она. Например нужно иметь пустого места достаточно, чтобы
> фрагментация не убила производительность в ноль. То есть, вместо 10 TB
> диска вы получите 8 чтобы всё было более менее (хотя если речь про
> хранение последовательно записанных файлов только для чтения, типа
> хранилки фильмов, музыки, архивов с бэкапами, то можно чуть ли не битком
> набивать).
O_O
Вы хотите сказать, что она жрёт 20% места под метаданные?!
Или что она просто начинает сильно фрагментироваться, при заполнении?
Во втором случае, ведь должна быть онлайн дефрагментация...

> На 32-бит системах она вроде как официально даже не
> поддерживается.
> 
32 бита ушли из того сегмента, где нужна ZFS.

Re: ZFS

[Sergey Matveev]

*** artiom  [2017-06-25 00:21]:
>Там и сжатие есть?

Я вот тут упомянул: 
https://lists.debian.org/debian-russian/2017/06/msg00618.html
что у меня на практике 60 GB MongoDB превратилась в 20 GB занятого места
и соответственно в памяти кэш ФС тоже в три раза меньше жрёт. Это если
LZ4 сжатие, которое очень CPU дешёвое. По-умолчанию оно отключено, если что.

>У вас прям по ZFS сплошные плюсы.
>Вы, случаем, не её разработчик, так нахваливаете? :-)
>Минусы-то, недоработки и баги у неё какие есть?

Я очень консервативен и моё внимание сложно привлечь новинкой, чаще я
скажу "очередное хипсторское поделие" (честно говоря я с Debian ушёл
из-за его systemd по-умолчанию, хотя использовал 7 лет). Но вот ZFS,
действительно удивительно, оказалась для меня неким Святым Граалем в
мире ФС/RAID/LVM/etc. Нет, я не её разработчик, денег за хорошие слова в
её сторону не получаю :-). Просто в искреннем восторге от неё и за все
годы знакомства с ней и использования жалел только о том, что раньше и
активнее не начал её использовать.

Минус наверное могу сказать только тот, что не всегда понятно как лучше
поднастроить её для хорошей производительности например под СУБД. RAIDZ
можно сконфигурировать так, что там будут очень большие потери места
впустую. Все эти шаманства с разными размерами блоков... без этого
никуда, ведь ZFS не может же знать какие прикладные задачи поверх неё вы
применяете. Хотя наверное это относится к любой ФС/mdadm/LVM -- tuning
касается всего, но на ZFS это может отражаться в десятках процентах или
даже разов. В общем опыт и понимание нужны.

Дорогая она. Например нужно иметь пустого места достаточно, чтобы
фрагментация не убила производительность в ноль. То есть, вместо 10 TB
диска вы получите 8 чтобы всё было более менее (хотя если речь про
хранение последовательно записанных файлов только для чтения, типа
хранилки фильмов, музыки, архивов с бэкапами, то можно чуть ли не битком
набивать). На 32-бит системах она вроде как официально даже не
поддерживается.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

[artiom]

>> И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта суммой
>> из всего этого уже забито, я собираюсь ставить 4-терабайтник,
>> вероятно. На работе имеется в виду держать зеркало из пары
>> 4-терабайтников.
>>
>> В обоих случаях супербыстрый доступ не требуется, но и суровых тормозов
>> быть не должно. 
>>
>> Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
>> более-менее комфортно? А если я захочу дедупликацию включить?  (Кстати,
>> ее можно включить/выключить на ходу, или это надо делать в момент
>> создания FS?)
> 
> 8 гигабайт точно хватит, а вот с 4-мя терзают сомнения. А вот если
> хочется включить дедупликацию, то, личного опыта нет, но говорят что
> нужно примерно 5 гигабайт RAM на каждый терабайт данных.
Вот, кстати. Память она жрёт, при включенном дедупе, я вспомнил.
И память с ECC, соответственно, тоже нужна при включении дедупа.
Вот только нужен и он на хранилище?

> То есть в
> случае с 4 TB дисками, лучше бы иметь более 20 гигабайт. Дедупликацию
> можно включить на уже работающей системе, когда угодно, как и выключить.
> А точно вам нужна дедупликация? Вот например прозрачное сжатие LZ4 штука
> я считаю почти всегда не помешающая (zfs set compression=lz4 mypool), а
> вот дедупликация...
Там и сжатие есть?

> я за несколько лет так и не смог увидеть в домашних
> условиях где бы это могло помочь. Если делаются какие-то "ответвления"
> типа clone или там snapshot (например есть chroot какой-нибудь ОС,
> хочется из него наделать разных других chroot-ов для контейнеров) -- то
> там и так только дельты хранятся. Где-то я чуть ли не в официальных
> мануалах Sun-а (Oracle?) видел что зачастую правильное использование
> clone-ов (snapshot и прочего) решает большинство проблем с
> избыточностью, где люди думают о дедупликации. Хотя если это
> какой-нибудь там хостинг картиночек, где одни и те же кошечки тысячами
> пользователей заливаются, то там поможет. В ZFS есть команда zdb -S
> mypool которая "эмулирует" дедупликацию и показывает поможет ли она или
> нет. Буквально вчера на одном из разделов её делал у себя (подумал что
> может пора?):
> 
> # zdb -S storage
> Simulated DDT histogram:
> 
> bucket  allocated   referenced
> __   __   __
> refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
> --   --   -   -   -   --   -   -   -
>  18.87M   1.11T   1.10T   1.10T8.87M   1.11T   1.10T   1.10T
>  26.31K807M782M782M13.0K   1.63G   1.57G   1.57G
>  4  250   31.2M   27.2M   27.2M1.08K138M120M120M
>  8   11   1.38M653K653K  102   12.8M   5.61M   5.61M
> 167896K134K134K  156   19.5M   2.38M   2.38M
> 321128K   20.5K   20.5K   52   6.50M   1.04M   1.04M
>  Total8.88M   1.11T   1.10T   1.10T8.89M   1.11T   1.11T   1.11T
> 
> dedup = 1.00, compress = 1.00, copies = 1.00, dedup * compress / copies = 
> 1.01
> 
> Видно что о ней думать не приходится совершенно.
> 
У вас прям по ZFS сплошные плюсы.
Вы, случаем, не её разработчик, так нахваливаете? :-)
Минусы-то, недоработки и баги у неё какие есть?

Re: ZFS

[artiom]

24.06.2017 19:33, Igor Savlook пишет:
> On Sat, 2017-06-24 at 19:23 +0300, Artem Chuprina wrote:
>> Igor Savlook -> debian-russian@lists.debian.org  @ Sat, 24 Jun 2017
>> 18:42:44 +0300:
>>
>>  >> Граждане, раз уж пошла такая пьянка.
>>  >> 
>>  >> Я правильно понимаю, что если я, допустим, хочу хранить
>>  >> бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки
>>  >> ставить
>>  >> на нормальный раздел, а не на zfs же? А zfs разворачивать поверх
>>  >> второго
>>  >> раздела?
>>  >> 
>>  >> А если я, допустим, хочу рейд на нескольких дисках, то поделить
>>  >> каждый
>>  >> так же на два раздела, на первых сделать raid1 с системой, а на
>>  >> вторых
>>  >> собирать raidz?
>>  >> 
>>  >> Потому что систему на zfs я если и водружу, то в случае сбоя хрен
>> я к
>>  >> файловой системе штатными средствами бутовой флешки доберусь?
>>  >> 
>>  >> Это я задумываюсь про апгрейд двух серверов - домашнего, который
>> он
>>  >> же
>>  >> файлообменник, и бэкап-сервера на работе. Дома в норме один диск,
>> на
>>  >> работе - рейд.
>>  >> 
>>  >> И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта
>>  >> суммой
>>  >> из всего этого уже забито, я собираюсь ставить 4-терабайтник,
>>  >> вероятно. На работе имеется в виду держать зеркало из пары
>>  >> 4-терабайтников.
>>  >> 
>>  >> В обоих случаях супербыстрый доступ не требуется, но и суровых
>>  >> тормозов
>>  >> быть не должно. 
>>  >> 
>>  >> Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
>>  >> более-менее комфортно? А если я захочу дедупликацию
>>  >> включить?  (Кстати,
>>  >> ее можно включить/выключить на ходу, или это надо делать в момент
>>  >> создания FS?)
>>  >> 
>>  > Просто технически интересно, а что если, вдруг, раз и поддержу zfs
>> для
>>  > линухи прекратят? Что тогда ты будешь делать? Вроде как на замену
>> zfs
>>  > пилят и пилят и пилят btfs но успеха нет а вот доверять zfs чет
>> тоже
>>  > как-то стремно. Приходится пока сидеть на mdadm.
>>
>> Что значит "прекратят"? На серверах у меня stable, в рамках stable не
>> прекратят.
>>
> Ну и что, вот вышел у нас stretch в stable а пакета virtualbox не
> оказалось. Но я не про то. Я про то что вдруг сами ментейнеры zfs для
> линухи махнут на него рукой.
> 
Крайне сомнительно.
Нафиг тогда нужен будет ZFS?
Или они из принципа: будут соляру и BSD развивать?

Re: ZFS

[Sergey Matveev]

*** Artem Chuprina  [2017-06-24 22:49]:
>Я правильно понимаю, что если я, допустим, хочу хранить
>бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки ставить
>на нормальный раздел, а не на zfs же? А zfs разворачивать поверх второго
>раздела?
>
>А если я, допустим, хочу рейд на нескольких дисках, то поделить каждый
>так же на два раздела, на первых сделать raid1 с системой, а на вторых
>собирать raidz?
>
>Потому что систему на zfs я если и водружу, то в случае сбоя хрен я к
>файловой системе штатными средствами бутовой флешки доберусь?

Не знаю как в GNU/Linux, но не могу представить в чём может быть
проблема или подстава достучаться до ФС с бутовой флешки? Загрузились на
"LiveCD" с флешки, сделали zpool import mypool и всё. Ну ok, как правило
оно захочет подмонтировать сразу же и поэтому перед этим надо указать
другую директорию монтирования. Я так делал много раз, просто указывая
какой-нибудь /tmp/mypool. Я не понял в чём проблемы держать систему на
ZFS. Там это очень кстати бы было если например делается какой-нибудь
dist-upgrade и хочется откатиться до начального состояния в случае
проблем.

>И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта суммой
>из всего этого уже забито, я собираюсь ставить 4-терабайтник,
>вероятно. На работе имеется в виду держать зеркало из пары
>4-терабайтников.
>
>В обоих случаях супербыстрый доступ не требуется, но и суровых тормозов
>быть не должно. 
>
>Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
>более-менее комфортно? А если я захочу дедупликацию включить?  (Кстати,
>ее можно включить/выключить на ходу, или это надо делать в момент
>создания FS?)

8 гигабайт точно хватит, а вот с 4-мя терзают сомнения. А вот если
хочется включить дедупликацию, то, личного опыта нет, но говорят что
нужно примерно 5 гигабайт RAM на каждый терабайт данных. То есть в
случае с 4 TB дисками, лучше бы иметь более 20 гигабайт. Дедупликацию
можно включить на уже работающей системе, когда угодно, как и выключить.
А точно вам нужна дедупликация? Вот например прозрачное сжатие LZ4 штука
я считаю почти всегда не помешающая (zfs set compression=lz4 mypool), а
вот дедупликация... я за несколько лет так и не смог увидеть в домашних
условиях где бы это могло помочь. Если делаются какие-то "ответвления"
типа clone или там snapshot (например есть chroot какой-нибудь ОС,
хочется из него наделать разных других chroot-ов для контейнеров) -- то
там и так только дельты хранятся. Где-то я чуть ли не в официальных
мануалах Sun-а (Oracle?) видел что зачастую правильное использование
clone-ов (snapshot и прочего) решает большинство проблем с
избыточностью, где люди думают о дедупликации. Хотя если это
какой-нибудь там хостинг картиночек, где одни и те же кошечки тысячами
пользователей заливаются, то там поможет. В ZFS есть команда zdb -S
mypool которая "эмулирует" дедупликацию и показывает поможет ли она или
нет. Буквально вчера на одном из разделов её делал у себя (подумал что
может пора?):

# zdb -S storage
Simulated DDT histogram:

bucket  allocated   referenced
__   __   __
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
--   --   -   -   -   --   -   -   -
 18.87M   1.11T   1.10T   1.10T8.87M   1.11T   1.10T   1.10T
 26.31K807M782M782M13.0K   1.63G   1.57G   1.57G
 4  250   31.2M   27.2M   27.2M1.08K138M120M120M
 8   11   1.38M653K653K  102   12.8M   5.61M   5.61M
167896K134K134K  156   19.5M   2.38M   2.38M
321128K   20.5K   20.5K   52   6.50M   1.04M   1.04M
 Total8.88M   1.11T   1.10T   1.10T8.89M   1.11T   1.11T   1.11T

dedup = 1.00, compress = 1.00, copies = 1.00, dedup * compress / copies = 
1.01

Видно что о ней думать не приходится совершенно.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: ZFS

[Igor Savlook]

On Sat, 2017-06-24 at 19:51 +0300, Artem Chuprina wrote:
> Igor Savlook -> debian-russian@lists.debian.org  @ Sat, 24 Jun 2017
> 19:33:32 +0300:
> 
>  >>  > Просто технически интересно, а что если, вдруг, раз и поддержу
> zfs
>  >> для
>  >>  > линухи прекратят? Что тогда ты будешь делать? Вроде как на
> замену
>  >> zfs
>  >>  > пилят и пилят и пилят btfs но успеха нет а вот доверять zfs
> чет
>  >> тоже
>  >>  > как-то стремно. Приходится пока сидеть на mdadm.
>  >> 
>  >> Что значит "прекратят"? На серверах у меня stable, в рамках
> stable не
>  >> прекратят.
>  >> 
>  > Ну и что, вот вышел у нас stretch в stable а пакета virtualbox не
>  > оказалось. Но я не про то. Я про то что вдруг сами ментейнеры zfs
> для
>  > линухи махнут на него рукой.
> 
> Поясняю. Прямо на ходу поддержка не пропадет. Чтобы пропала, надо
> сапгрейдиться на следующую major версию. Это будет запас года два как
> минимум.
> 
Просто интересно много-ли народу пили zfs для linux. Тоже подумывал о
переходе на него но чет пока сомневаюсь.

Re: ZFS

[Artem Chuprina]

Igor Savlook -> debian-russian@lists.debian.org  @ Sat, 24 Jun 2017 19:33:32 
+0300:

 >>  > Просто технически интересно, а что если, вдруг, раз и поддержу zfs
 >> для
 >>  > линухи прекратят? Что тогда ты будешь делать? Вроде как на замену
 >> zfs
 >>  > пилят и пилят и пилят btfs но успеха нет а вот доверять zfs чет
 >> тоже
 >>  > как-то стремно. Приходится пока сидеть на mdadm.
 >> 
 >> Что значит "прекратят"? На серверах у меня stable, в рамках stable не
 >> прекратят.
 >> 
 > Ну и что, вот вышел у нас stretch в stable а пакета virtualbox не
 > оказалось. Но я не про то. Я про то что вдруг сами ментейнеры zfs для
 > линухи махнут на него рукой.

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

Re: ZFS

[Igor Savlook]

On Sat, 2017-06-24 at 19:23 +0300, Artem Chuprina wrote:
> Igor Savlook -> debian-russian@lists.debian.org  @ Sat, 24 Jun 2017
> 18:42:44 +0300:
> 
>  >> Граждане, раз уж пошла такая пьянка.
>  >> 
>  >> Я правильно понимаю, что если я, допустим, хочу хранить
>  >> бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки
>  >> ставить
>  >> на нормальный раздел, а не на zfs же? А zfs разворачивать поверх
>  >> второго
>  >> раздела?
>  >> 
>  >> А если я, допустим, хочу рейд на нескольких дисках, то поделить
>  >> каждый
>  >> так же на два раздела, на первых сделать raid1 с системой, а на
>  >> вторых
>  >> собирать raidz?
>  >> 
>  >> Потому что систему на zfs я если и водружу, то в случае сбоя хрен
> я к
>  >> файловой системе штатными средствами бутовой флешки доберусь?
>  >> 
>  >> Это я задумываюсь про апгрейд двух серверов - домашнего, который
> он
>  >> же
>  >> файлообменник, и бэкап-сервера на работе. Дома в норме один диск,
> на
>  >> работе - рейд.
>  >> 
>  >> И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта
>  >> суммой
>  >> из всего этого уже забито, я собираюсь ставить 4-терабайтник,
>  >> вероятно. На работе имеется в виду держать зеркало из пары
>  >> 4-терабайтников.
>  >> 
>  >> В обоих случаях супербыстрый доступ не требуется, но и суровых
>  >> тормозов
>  >> быть не должно. 
>  >> 
>  >> Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
>  >> более-менее комфортно? А если я захочу дедупликацию
>  >> включить?  (Кстати,
>  >> ее можно включить/выключить на ходу, или это надо делать в момент
>  >> создания FS?)
>  >> 
>  > Просто технически интересно, а что если, вдруг, раз и поддержу zfs
> для
>  > линухи прекратят? Что тогда ты будешь делать? Вроде как на замену
> zfs
>  > пилят и пилят и пилят btfs но успеха нет а вот доверять zfs чет
> тоже
>  > как-то стремно. Приходится пока сидеть на mdadm.
> 
> Что значит "прекратят"? На серверах у меня stable, в рамках stable не
> прекратят.
> 
Ну и что, вот вышел у нас stretch в stable а пакета virtualbox не
оказалось. Но я не про то. Я про то что вдруг сами ментейнеры zfs для
линухи махнут на него рукой.

Re: ZFS

[Artem Chuprina]

Igor Savlook -> debian-russian@lists.debian.org  @ Sat, 24 Jun 2017 18:42:44 
+0300:

 >> Граждане, раз уж пошла такая пьянка.
 >> 
 >> Я правильно понимаю, что если я, допустим, хочу хранить
 >> бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки
 >> ставить
 >> на нормальный раздел, а не на zfs же? А zfs разворачивать поверх
 >> второго
 >> раздела?
 >> 
 >> А если я, допустим, хочу рейд на нескольких дисках, то поделить
 >> каждый
 >> так же на два раздела, на первых сделать raid1 с системой, а на
 >> вторых
 >> собирать raidz?
 >> 
 >> Потому что систему на zfs я если и водружу, то в случае сбоя хрен я к
 >> файловой системе штатными средствами бутовой флешки доберусь?
 >> 
 >> Это я задумываюсь про апгрейд двух серверов - домашнего, который он
 >> же
 >> файлообменник, и бэкап-сервера на работе. Дома в норме один диск, на
 >> работе - рейд.
 >> 
 >> И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта
 >> суммой
 >> из всего этого уже забито, я собираюсь ставить 4-терабайтник,
 >> вероятно. На работе имеется в виду держать зеркало из пары
 >> 4-терабайтников.
 >> 
 >> В обоих случаях супербыстрый доступ не требуется, но и суровых
 >> тормозов
 >> быть не должно. 
 >> 
 >> Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
 >> более-менее комфортно? А если я захочу дедупликацию
 >> включить?  (Кстати,
 >> ее можно включить/выключить на ходу, или это надо делать в момент
 >> создания FS?)
 >> 
 > Просто технически интересно, а что если, вдруг, раз и поддержу zfs для
 > линухи прекратят? Что тогда ты будешь делать? Вроде как на замену zfs
 > пилят и пилят и пилят btfs но успеха нет а вот доверять zfs чет тоже
 > как-то стремно. Приходится пока сидеть на mdadm.

Что значит "прекратят"? На серверах у меня stable, в рамках stable не
прекратят.

Re: ZFS

[Igor Savlook]

On Sat, 2017-06-24 at 15:01 +0300, Artem Chuprina wrote:
> Граждане, раз уж пошла такая пьянка.
> 
> Я правильно понимаю, что если я, допустим, хочу хранить
> бэкапы/архивы/файлообменник на zfs, мне стоит систему все-таки
> ставить
> на нормальный раздел, а не на zfs же? А zfs разворачивать поверх
> второго
> раздела?
> 
> А если я, допустим, хочу рейд на нескольких дисках, то поделить
> каждый
> так же на два раздела, на первых сделать raid1 с системой, а на
> вторых
> собирать raidz?
> 
> Потому что систему на zfs я если и водружу, то в случае сбоя хрен я к
> файловой системе штатными средствами бутовой флешки доберусь?
> 
> Это я задумываюсь про апгрейд двух серверов - домашнего, который он
> же
> файлообменник, и бэкап-сервера на работе. Дома в норме один диск, на
> работе - рейд.
> 
> И второй вопрос, к тем, кто имеет опыт. Дома у меня 2 терабайта
> суммой
> из всего этого уже забито, я собираюсь ставить 4-терабайтник,
> вероятно. На работе имеется в виду держать зеркало из пары
> 4-терабайтников.
> 
> В обоих случаях супербыстрый доступ не требуется, но и суровых
> тормозов
> быть не должно. 
> 
> Сколько надо памяти, чтобы zfs чувствовала себя в этих условиях
> более-менее комфортно? А если я захочу дедупликацию
> включить?  (Кстати,
> ее можно включить/выключить на ходу, или это надо делать в момент
> создания FS?)
> 
Просто технически интересно, а что если, вдруг, раз и поддержу zfs для
линухи прекратят? Что тогда ты будешь делать? Вроде как на замену zfs
пилят и пилят и пилят btfs но успеха нет а вот доверять zfs чет тоже
как-то стремно. Приходится пока сидеть на mdadm.