Что: 1c64cce5d29d8bfff067f5f873af3024971b979c
Когда: 2020-01-08 15:50:11+03:00
------------------------------------------------------------------------
Темы: zfs
------------------------------------------------------------------------
Посмотрел как собирается сервер зеркало Debian-а Дмитрием Бачилой

http://16-bits.ru/allunix-desktop-linux/
Дмитрий всё делает в общем-то правильно, претензий нет. Но включу зануду
касательно работы с ZFS-ом:

* во время загрузки у Дмитрия действительно вываливались SATA ошибки и
  всё же нужно проверить каждый диск всё ли с ним в порядке. Возможно с
  диском проблемы, скорее всего с питанием или SATA-кабелем (90% всех
  проблем из-за контактов/кабелей). Но для видео, думаю, это было бы
  излишне и не интересно
* я не очень понимаю почему сама система поставлена на UFS2, а не на
  ZFS, с которым без проблем FreeBSD может загрузиться (ну, ok, с
  ограничениями на ряд фич включённых). Как минимум это дико удобно для
  администрирования и создания backup-ов
* в свете последних мною узнанных особенностей, приходится
  самостоятельно для простых SATA дисков делать хаки
  (2a6f0070761d6b8831998a5150cf31e39d7f4be0) чтобы заставить pool
  использовать 4K секторы. А диски тут не то что обычные SATA, но даже
  вот с заранее созданной NTFS. У Дмитрия я уверен что создались 512B
  секторы, что не очень хорошо будет для производительности
* сам я не сталкивался, но, много говорят, что могут возникнуть проблемы
  если диски "переименуются" и ZFS может не найти их все, при сборке
  pool-а после перезагрузки. Поэтому рекомендуется создавать pool поверх
  чего-то более стабильного чем пронумерованные диски. Использовать
  diskid/SERIAL, использовать glabel (label/LABEL) или GPT (gpt/LABEL)
  GPT в довесок автоматом можно использовать и для выравнивания раздела
  по 4K границам. Да и просто как-то приятнее видеть *хотя бы* серийные
  номера дисков в zpool list, а не просто голые ada0/1/2. А ещё я слышал
  люди GPT разделы делают например на 1 GB поменьше, чтобы, при вставке
  совершенно других дисков, немного несовпадающие размеры (ведь никто же
  ровно терабайты эти не делает?) не означали бы невозможность
  подсоединения диска к pool-у. А ещё GPT полезны когда захочется
  использовать ZFS для основной системы и выделить отдельную партицию
  для swap-а, который вряд ли захочется менять по размерам когда-либо
* после/при создании pool-а для зеркала я бы однозначно включал:
  * atime=off (тупо экономия IOPS-ов на вряд ли нужные atime)
  * recordsize=1M (для хранения Debian пакетов оно в самый раз -- просто
    класть линейным куском и не думать, так будет меньше фрагментация и
    меньше IOPS отжирать, плюс линейное размещение блока)
  * compression=lz4 (компрессия нужна, как минимум, для удаления нулевых
    блоков, да и вообще не помешает LZ4, который быстро fallback делает
    если данные не сжимаются. Как правило, ситуаций когда компрессия LZ4
    может навредить нету)
  * checksum=skein (лично я бы не хотел не криптографические хэши.
    SHA256 вариант, но Skein или SHA512 будут быстрее. Теоретически,
    если захочется дедупликации, то криптохэши придётся включить в любом
    случае)

------------------------------------------------------------------------
оставить комментарий: mailto:comment@blog.stargrave.org?subject=Re:%20%D0%9F%D0%BE%D1%81%D0%BC%D0%BE%D1%82%D1%80%D0%B5%D0%BB%20%D0%BA%D0%B0%D0%BA%20%D1%81%D0%BE%D0%B1%D0%B8%D1%80%D0%B0%D0%B5%D1%82%D1%81%D1%8F%20%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%20%D0%B7%D0%B5%D1%80%D0%BA%D0%B0%D0%BB%D0%BE%20Debian-%D0%B0%20%D0%94%D0%BC%D0%B8%D1%82%D1%80%D0%B8%D0%B5%D0%BC%20%D0%91%D0%B0%D1%87%D0%B8%D0%BB%D0%BE%D0%B9%20%281c64cce5d29d8bfff067f5f873af3024971b979c%29

------------------------------------------------------------------------
Сгенерирован: SGBlog 0.34.0