From 1c64cce5d29d8bfff067f5f873af3024971b979c Mon Sep 17 00:00:00 2001
From: Sergey Matveev <stargrave@stargrave.org>
Date: Wed, 8 Jan 2020 15:50:11 +0300
Subject: [PATCH] =?utf8?q?=D0=9F=D0=BE=D1=81=D0=BC=D0=BE=D1=82=D1=80=D0=B5?=
 =?utf8?q?=D0=BB=20=D0=BA=D0=B0=D0=BA=20=D1=81=D0=BE=D0=B1=D0=B8=D1=80?=
 =?utf8?q?=D0=B0=D0=B5=D1=82=D1=81=D1=8F=20=D1=81=D0=B5=D1=80=D0=B2=D0=B5?=
 =?utf8?q?=D1=80=20=D0=B7=D0=B5=D1=80=D0=BA=D0=B0=D0=BB=D0=BE=20Debian-?=
 =?utf8?q?=D0=B0=20=D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B5=D0=BC=20?=
 =?utf8?q?=D0=91=D0=B0=D1=87=D0=B8=D0=BB=D0=BE=D0=B9?=
MIME-Version: 1.0
Content-Type: text/plain; charset=utf8
Content-Transfer-Encoding: 8bit

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 будут быстрее. Теоретически,
    если захочется дедупликации, то криптохэши придётся включить в любом
    случае)
-- 
2.51.0