From 1c64cce5d29d8bfff067f5f873af3024971b979c Mon Sep 17 00:00:00 2001 From: Sergey Matveev 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.50.0