Василий Зотов

если памяти 4г или больше, то однозначно zfs с архитектурой 64 бита.

основная причина - гибкость. при замене диска, например, gmirror будет зеркалить блочное устройство полностью, а zfs только часть, занятую данными. второе, разумеется, происходит гораздо быстрей.

но это не значит, что надо полностью отказаться от gmirror. своп на zfs размещать нельзя. т.е. технически сделать это получится, но когда система попытается им воспользоваться по причине нехватки памяти, то всё остановится, т.к. zfs будет пытаться кэшировать своп.

у меня дома атом с 4г памяти и сделано вот так:

[~@beat/08:35:26]
kelevra$ zpool status
  pool: zroot
 state: ONLINE
  scan: scrub repaired 0 in 5h36m with 0 errors on Thu Feb 25 07:36:18 2016
config:

        NAME           STATE     READ WRITE CKSUM
        zroot          ONLINE       0     0     0
          mirror-0     ONLINE       0     0     0
            gpt/root0  ONLINE       0     0     0
            gpt/root1  ONLINE       0     0     0

errors: No known data errors
[~@beat/08:35:29]
kelevra$ gmirror status
       Name    Status  Components
mirror/swap  COMPLETE  gpt/swap1 (ACTIVE)
                       gpt/swap0 (ACTIVE)
[~@beat/08:35:34]
kelevra$ gpart list ada0
Geom name: ada0
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 3907029134
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: ada0p1
   Mediasize: 65536 (64k)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r0w0e0
   rawuuid: 59c58842-1685-11e4-a3a3-7071bcb164bb
   rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
   label: boot0
   length: 65536
   offset: 20480
   type: freebsd-boot
   index: 1
   end: 167
   start: 40
2. Name: ada0p2
   Mediasize: 11811160064 (11G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r1w1e2
   rawuuid: 5b8cb655-1685-11e4-a3a3-7071bcb164bb
   rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
   label: swap0
   length: 11811160064
   offset: 86016
   type: freebsd-swap
   index: 2
   end: 23068839
   start: 168
3. Name: ada0p3
   Mediasize: 1986422374400 (1.8T)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r1w1e2
   rawuuid: 5e05979f-1685-11e4-a3a3-7071bcb164bb
   rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
   label: root0
   length: 1986422374400
   offset: 11811246080
   type: freebsd-zfs
   index: 3
   end: 3902800039
   start: 23068840
Consumers:
1. Name: ada0
   Mediasize: 2000398934016 (1.8T)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r2w2e6

второй диск разбит так же. уже третий год идёт - полёт нормальный.

Если вопрос про домашний сервер -- то пофиг. Если в продакш куда-то, то ZFS удобнее. Да, она памяти требует несколько больше, но в основном это касается сценариев, при которых используется дедупликация. Дедупликацию, несмотря на потенциальную привлекательность, использовать дома нет смысла. Во-первых, там нечего дедуплицировать (домашние фотки не будут иметь общих блоков, чтобы хоть как-то профит от дедупликации возник). А во-вторых -- примерные требования к оперативке при включении дедупликации -- 5 Гб RAM на 1 Тб диске.

На ZFS есть компрессия, есть возможность сделать, чтобы файлы в определённом датасете имели N копий (вместо одной). Есть снапшоты. Ну и если основная цель стоит -- поморочиться в ZFS, то тоже вполне можно использовать. Так-то у нас сервера есть с 1 Гб оперативы, стоящие на ZFS, и вполне нормально себя чувствуют.

Host header forgery означает, что со стороны клиента прилетел запрос на
IP, на котором нет того домена, который фигурирует в поле "Host"
HTTP-запроса. Сквид резолвит имя домена из поля host и сверяет список
полученных IP на предмет наличия там того IP, на который ломится клиент.
Если такого IP в списке нет, то сквид отбивает такой запрос. Но в
обработчике этой ботвы есть баг:
bugs.squid-cache.org/show_bug.cgi?id=4099

Фикса для этого бага пока нет, есть парочка костылей, которые помогают снизить
вероятность срабатывания защиты от host header forgery.