Хозяйке на заметку

Системные требования FreeNAS 8.x ужасны

8

С удивлением обнаружил, что для работы FreeNAS 8.x необходимо минимум 4Gb оперативной памяти. Но сами разработчики сообщают, что для минимальной работы ZFS необходимы уже 6Gb. А какую-то производительность она будет показывать от 8Gb...

Ерунда, что даже в моём рабочем компьютере меньше памяти. Самая большая беда, что у материнских плат, формата mini-ITX, со впаянным процессором Intel Atom, которые наиболее удобны для создания домашнего сервера, максимальный объём памяти — 4Gb.

Т.е. для простого и недорогого домашнего сервера FreeNAS 8.x уже не подходит. И я не говорю, про то, что он до сих пор не поддерживает BitTorrent.

Видимо время искать аналогичную операционную систему, с меньшими системными требованиями. Возможно какой-нибудь Linux+Btrfs

Btrfs — ZFS под Linux?

2

На своём собственном файловом хранилище я использую файловую систему ZFS, т.к. она позволяет делать некоторые вещи, недоступные многим другим файловым системам. Для домашнего сервера, как я говорил, интереснее всего возможность создания снимков файловой системы и возможности отката к предыдущим состояниям. Это, например, позволяет восстанавливать случайно удалённые файлы.

ZFS доступна для операционных систем Solaris и FreeBSD. Но недоступна для LInux, которая также является популярной операционной системой для создания файловых серверов.

Но тут я наткнулся на файловую систему , которая работает под Linux, умеет делать снепшоты и многое другое. При этом она уже доступна в основных дистрибутивах Linux.

Так что Btrfs выглядит как интересный вариант файловый системы, для использования в домашних сетевых хранилищах данных, на основе LInux.

iSCSI — не для дома

2

Пришлось мне, по работе, разбираться с протоколом . Давно слышал, но в руки не попадал никогда.

Оказалось, что это протокол передачи по сети SCSI команд. При этом за создание файловой системы и прочего отвечает клиент (в терминологии iSCSI — iSCSI initiator), а сервер (iSCSI target) лишь предоставляет место и выполняет команды чтения/записи.

Вскрытие показало, что этот протокол имеет свои преимущества для промышленного хранения данных. Например возможность консолидации дисковых массивов на специальных серверах, со всеми вытекающими.

Но вот для дома, он мало применим, несмотря на поддержку и FileNodeOS, и FreeNAS. Т.к., как правило, предоставляет лишь монопольный доступ к данным. Т.е. в каждый момент времени может быть подсоединён только один клиент.

P.S. У меня возникла мысль, а не работает ли случайно Netgear Storage Central Turbo SC101T по этому протоколу. А то больно описание возможностей совпадает. Надо попробовать.

Занимательная дисковая арифметика для ZFS

0

Некоторое время назад я сокрушался, что от двух дисков по терабайту, после построения из них программного RAID 1, на UFS, осталось всего 830Gb места, доступного для хранения файлов.

После перехода на ZFS, зеркалирование данных теперь осуществляется файловой системой, картина довольно существенно изменилась:

> df -h /mnt/storage/
Filesystem    Size    Used   Avail Capacity  Mounted on
storage       916G    600G    317G    65%    /mnt/storage

Т.е. объём доступного файловому хранилищу места увеличился на 86Gb, с 830Gb до 916Gb. И этот показатель не уменьшается с заполнением диска, в отличии от предыдущей конфигурации хранилища, программный RAID 1 и UFS.

Таким образом, ZFS со всех сторон выглядит отличной файловой системой для домашнего сетевого хранилища. К предыдущим достоинствам добавился и больший объём доступного места.

Занимательная дисковая арифметика

6

Вот вы купили два терабайтных винчестера и хотите построить из них дисковый массив RAID 1. Сколько места вы ожидаете получить в итоге?

Теория RAID 1 говорит, что в итоге вы получите объём массива, равный одному терабайту. Однако реальность несколько отличается от этой теории.

Первым делом, не забывайте, что терабайтные винчестеры традиционно не терабайтные, а триллионбайтные. Таким образом, изготовители винчестеров бесплатно «увеличивают» маркетинговый объём. Поэтому мы уже имеем всего 931Gb вместо 1Tb.

Дальше интереснее. При постройке из двух терабайтных винчестеров программного RAID1 на FreeBSD получаем  902Gb свободного пространства. Т.е. 30Gb сразу съелось на служебную информацию.

Ну и уж вообще забавно получается после заполнения половины диска:

Filesystem           Size  Used  Avail Capacity  Mounted on
/dev/mirror/Storage1 902G  442G  388G    53%    /mnt/storage

Т.е. указано, что общий размер диска — 902Gb, занято — 442Gb, свободно — 388Gb. Ничего не настораживает?

442+388=830, а не 902. Куда, спрашивается ещ` 72Gb делось?

Таким образом вместо терабайта получили 830Gb. Из них 69Gb повисло на совести Western Digital — изготовителя дисков, а еще 100Gb съел программный RAID1.

Мне тут интересны три вопроса:

  1. С железным RAID1 такая же беда?
  2. Реализация программного RAID 1 на других операционных системах столь же прожорлива?
  3. 830GB — это окончательный объём или потом ещё пропадёт?

Не забывайте бекапить бекапы!

3

Вчера случайно выяснил с какой дикой скоростью FreeBSD удаляет файлы с UFS. Разбирал фотографии прямо на сервере и, как герой многих сисадминских анекдотов, напустил rm -rf Photos""...

Как показал осмотр разрушений, за те несколько секунд, что я осознавал, что я сделал и жал на отмену, сервер успел снести половину из почти сотни гигабайт фотографий. И если утерю фотографий с моего дня рождения восьмилетней давности ещё как-то можно пережить, то за потерю фотографий наших девочек, только что приехавших из роддома, жена бы меня точно убила.

Поиск по интернету способов восстановления удалённых файлов на UFS показал наличие нескольких специализированных программ. Но говорилось, что они восстанавливают всего около 40% удалённых файлов, что неприемлимо мало. Второй проблемой оказалось, что все найденные программы работали почему-то под Windows.

Спасла же меня найденная ещё одна копия фотографий на моём компьютере, забытая при переносе на NAS.

Мораль сей сказки проста: не забывайте бекапить бекапы! Держите несколько копий, синхронизируйте их регулярно rsync'ом, unison'ом или ещё чем-нибудь. Наличие ещё одной копии в каком-нибудь онлайновом хранилище не блажь, а суровая необходимость.

Нужно будет поисследовать журналируемые файловые системы с возможностью отката во времени...

Вверх