Поднимаем NFS на Debian

На самом деле задача тривиальная, займет не более 5-10 минут. Принцип настройки одинаков для всех дистрибутивов. Разница скорее всего будет только в установке NFS. Следующим постом опишу процедуру настройки Apple TimeMachine для резервного копирования в нашу новую NFS-шару.

Итак...

1. Устанавливаем NFS server

# sudo apt-get install nfs-kernel-server nfs-common portmap

устанавливаем NFS client

# sudo apt-get install nfs-common portmap

Для того, чтобы убедится что у вас все установилось и запустилось выполните:

# rpcinfo -p

В выводе должен присутствовать nfs и mountd.

2. Настраиваем NFS

Для начала необходимо определится с расположением шар на диске. У меня это внешний ЖД с точкой монтирования /var/nfs.

mkdir /var/nfs
chown nobody:nogroup /var/nfs

Необходимо отредактировать /etc/exports (свой привожу ниже, там у меня всего одна строчка, для моего макбука):

/var/nfs          macfrac (rw,no_root_squash,sync,no_subtree_check,insecure)

Разберем эту строку:

/var/nfs — путь до шары

macfrac — имя хоста, который будет иметь доступ к шаре. Если на шаге 3 будут проблемы с определением адреса хоста, то добавьте необходимую запись в /etc/hosts. Правила для этого хоста:

(rw,no_root_squash,sync,no_subtree_check,insecure)

Тут я думаю все понятно из названия опций (кстати, будет не лишним также почитать документацию и man для более точной настройки под себя)... Остановлюсь только на insecure — в моем случае не получилось сразу примонтировать шару на удаленном компе. mount сообщал «Operation not permited». Одна из причин данного сообщения — попытка подключения с неизвестного порта. Как результат — ничего не монтируется.  После указания данной опции все заработало.

3. Добавляем шару в список доступных для NFS

# sudo exportfs -a

Для проверки експорта смотрим список доступных в данный момент ФС)

# showmount -e

В принципе, шару можно считать настроенной. Как подключить шару с хоста macfrac?! Вот рабочий (у меня) пример команды mount:

# sudo mount -t nfs <IP-адрес сервера NFS>:/var/nfs /media/nfs

Performance Tuning

NFS does not need a fast processor or a lot of memory. I/O is the bottleneck, so fast disks and a fast network help. If you use IDE disks, use hdparam to tune them for optimal transfer rates. If you support multiple, simultaneous users, consider paying for SCSI disks; SCSI can schedule multiple, interleaved requests much more intelligently than IDE can.

On the software side, by far the most effective step you can take is to optimize the NFS block size. NFS transfers data in chunks. If the chunks are too small, your computers spend more time processing chunk headers than moving bits. If the chunks are too large, your computers move more bits than they need to for a given set of data. To optimize the NFS block size, measure the transfer time for various block size values. Here is a measurement of the transfer time for a 256 MB file full of zeros.

# mount files.first.com:/home /mnt -o rw,wsize=1024
# time dd if=/dev/zero of=/mnt/test bs=16k count=16k
16384+0 records in
16384+0 records out

real 0m32.207s
user 0m0.000s
sys 0m0.990s

# umount /mnt

This corresponds to a throughput of 63 Mb/s.
Try writing with block sizes of 1024, 2048, 4096, and 8192 bytes (if you use NFS v3, you can try 16384 and 32768, too) and measuring the time required for each. In order to get an idea of the uncertainly in your measurements, repeat each measurement several times. In order to defeat caching, be sure to unmount and remount between measurements.

# mount files.first.com:/home /mnt -o ro,rsize=1024
# time dd if=/mnt/test of=/dev/null bs=16k
16384+0 records in
16384+0 records out

real 0m26.772s
user 0m0.010s
sys 0m0.530s

# umount /mnt

Your optimal block sizes for both reading and writing will almost certainly exceed 1024 bytes. It may occur that, like mine, your data do not indicate a clear optimum, but instead seem to approach an asymptote as block size is increased. In this case, you should pick the lowest block size which gets you close to the asymptote, rather than the highest available block size; anecdotal evidence indicates that too large block sizes can cause problems.