> Что бесит - примитивная хранилка, но обязательно - х64... Зачем?! затем, что "примитивная хранилка", ворочающая полудесятком терабайт (для дома для семьи, внезапно, уже не особо и много), внезапно, требует немаленькой памяти, чтобы хранить с них хотя бы метаинформацию в кэше (потому что ее, внезапно, тоже много), а не елозить по дискам.
Да, все это кое-как еще можно собрать (с кучей trade-off'ов), но уже совершенно никому неинтересно поддерживать.
> валяется куча старых NAS - отличная коробка, но... железо х86_32 и
> убогая родная прошивка. Туда бы что-то альтернативное, тот же OMV... По
ну соберите (хотя, подозреваю, оно и так в repo есть). Ставите банальный debian, дальше - см. рецепт от kvaps выше по форуму. Пункты про proxmox и zfs можете пропустить (а можете и не, чисто поржать).
> онли, если оно там в принципе не нужно? Это же не
> ZFS с дедупликацией и прочими фишками, жрущими ОЗУ как свинья апельсины...
сказки о zfs сильно преувеличены:
last pid: 59250; load averages: 0.30, 0.47, 0.47 up 22+04:55:31 10:39:06
27 processes: 2 running, 25 sleeping
CPU: % user, % nice, % system, % interrupt, % idle
Mem: 2768K Active, 98M Inact, 892K Laundry, 762M Wired, 118M Free
ARC: 454M Total, 162M MFU, 189M MRU, 32K Anon, 6318K Header, 96M Other
Swap: 1024M Total, 38M Used, 986M Free, 3% Inuse
это, если кто не понял, однопроцессорная виртуалка с гигом оперативы. Собственное ведро пересобрать - вполне может (и не за три с половиной часа). dedup, правда, не поместился, lz4 - поместился.
Но вот если начать раздавать с нее файлы - оно будет _очень_и_очень_медленно. И проблема ни разу не в zfs.
