Посмотрел как собирается сервер зеркало Debian-а Дмитрием Бачилой

Что: 1c64cce5d29d8bfff067f5f873af3024971b979c

Когда: 2020-01-08 15:50:11+03:00

Темы: zfs

Посмотрел как собирается сервер зеркало Debian-а Дмитрием Бачилой

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


  всё же нужно проверить каждый диск всё ли с ним в порядке. Возможно с
  диском проблемы, скорее всего с питанием или SATA-кабелем (90% всех
  проблем из-за контактов/кабелей). Но для видео, думаю, это было бы
  излишне и не интересно

  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-а, который вряд ли захочется менять по размерам когда-либо

  * atime=off (тупо экономия IOPS-ов на вряд ли нужные atime)
  * recordsize=1M (для хранения Debian пакетов оно в самый раз -- просто
    класть линейным куском и не думать, так будет меньше фрагментация и
    меньше IOPS отжирать, плюс линейное размещение блока)
  * compression=lz4 (компрессия нужна, как минимум, для удаления нулевых
    блоков, да и вообще не помешает LZ4, который быстро fallback делает
    если данные не сжимаются. Как правило, ситуаций когда компрессия LZ4
    может навредить нету)
  * checksum=skein (лично я бы не хотел не криптографические хэши.
    SHA256 вариант, но Skein или SHA512 будут быстрее. Теоретически,
    если захочется дедупликации, то криптохэши придётся включить в любом
    случае)

оставить комментарий

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