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.

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

[Artem Chuprina]

Я тут в процессе установки stretch в позу root on ZFS произвел некоторое 
переосмысление привычек управления файловой системой, и хочу поделиться. Если 
кто-нибудь напишет что-нибудь умное в ответ, как концептуальное, так и 
практическое, я как минимум с благодарностью прочитаю, а если будет что 
обсудить, то и обсужу. Извините, многабукф.

В качестве материала были скрипт Hajo Noerenberg 
https://github.com/hn/debian-stretch-zfs-root и вики-статья Richard Laager 
https://github.com/zfsonlinux/zfs/wiki/Debian-Jessie-Root-on-ZFS

Я так понимаю, статья первична, она с тех пор правилась неоднократно. Работа 
Нёренберга ценна в первую очередь тем, что некоторые технические, но важные 
моменты из вики-статьи там доведены до работающего кода. Или не работающего, 
если автору не свезло его протестировать :), я ему push request отправил. 
Некоторые из них действительно надо скриптовать, потому что шансов ошибиться 
там немало. Однако, в плане выделения файловых систем он, на мой взгляд, пошел 
по пути простому, но неправильному.

Лаагер, создавая файловые системы в пуле, явно говорит: "я стараюсь отделить 
систему от пользовательских данных, чтобы, если потребовалось после неудачного 
апгрейда откатывать /, не откатился заодно /var/log, где могут быть логи 
неудач". Да, /var/log он рассматривает как пользовательские данные.

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

Добавляя к философии практику, он

- При создании пула dataset'у пула прописывает canmount=off
  mountpoint=/. Штатное употребление canmount=off, очень удобно для
  наследования точек монтирования у подсистем. Нёренберг в скрипте не
  использует этого, а зря. Отмечу как важный момент.

- Делает по образцу и для возможной будущей совместимости с утилитами
  исходного соляриса контейнер rpool/ROOT (mountpoint=none, кажется) для
  корневых FS и внутри него уже создает rpool/ROOT/debian с mountpoint=/ и
  canmount=noauto — типа, монтирует его initrd. Мне canmount=noauto в этом
  месте не понравилось — если придется пул импортировать со стороны, придется
  цеплять его в три команды, а не в одну, и это если не забыть сразу
  импортировать с -N. С другой стороны, это пока у нас там один рут, а
  остальные — снапшоты. Как я подозреваю, в исходном солярисе их реально может
  быть несколько. У нас потенциально тоже ничто не мешает, и даже иметь их от
  разных дистрибутивов, а при некоторой аккуратности и разных ОС. Тогда noauto
  станет нужным.

- Делает rpool/var немонтируемым (canmount=off) dataset'ом с
  exec=off. Т.е. поддиректории /var сами по себе расположены в
  rpool/ROOT/debian, кроме явно созданных датасетов. Тут с точки зрения
  администрирования интересно exec=off, которое потом отдельно оверрайдится
  для rpool/var/tmp, а остальные датасеты наследуют. Хотелось бы понять, есть
  ли в этом смысл с учетом того, что изрядная часть /var расположена в
  корневом датасете, где exec вполне себе yes. И для /var/lib/dpkg/info,
  например, он нужен. А если идти дальше, то, например, LXC формирует образы
  систем тоже под /var/lib. Понятно, что для них отдельные датасеты, но в них,
  опять, exec надо. Тут вот нужен бы некий практический опыт на тему того, что
  еще у нас живет под /var, и нужно ли ему exec.

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

- Говорит о выделении таких мест, как /var/lib/postgresql, если он у кого есть
  (а где-то мне попадалось выделение еще и отдельного датасета под его xlog,
  там типа другие настройки), /var/games, если у кого стоят игры,
  /var/lib/nfs, у кого используется NFS, для локов, и т.п. Короче, о
  художественном выпиливании лобзиком по /var и