From 2a6f0070761d6b8831998a5150cf31e39d7f4be0 Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Fri, 27 Dec 2019 23:48:44 +0300 Subject: [PATCH] =?utf8?q?=D0=9F=D0=BE=D0=BB=D0=BD=D0=BE=D1=81=D1=82=D1=8C?= =?utf8?q?=D1=8E=20=D0=BF=D0=B5=D1=80=D0=B5=D0=B5=D1=85=D0=B0=D0=BB=20?= =?utf8?q?=D0=BD=D0=B0=20ashift=3D12=20=D0=BD=D0=B0=20=D0=B4=D0=BE=D0=BC?= =?utf8?q?=D0=B0=D1=88=D0=BD=D0=B8=D1=85=20=D1=81=D0=B5=D1=80=D0=B2=D0=B5?= =?utf8?q?=D1=80=D0=B0=D1=85?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit Зашифрованные разделы, так как они поверх GELI, проблем не создавали: zpool команда понимала что находится на блочном устройстве с 4K секторами. В ZoL, насколько вижу, можно -o ashift=12 указывать при создании pool-а, но в FreeBSD он такой опции не знает. А жёсткие диски все до одного врут что они 512 байт сектора имеют. Вспомнил тут про NOP, которым никогда не пользовался. Но он как-раз идеально подошёл чтобы "обмануть" ZFS: gnop create -S4K DEV и создаём zpool поверх DEV.nop устройства. То что .nop пропадёт -- ничего страшного: pool всё-равно подхватывается без проблем. -- 2.48.1