Производительность петлевых файловых систем

Кто-нибудь делал какие-либо тесты производительности / бенчмаркинга в петлевых файловых системах Linux? Каким был ваш опыт? Есть ли серьезное снижение производительности? Как насчет надежности?

http://freshmeat.net/articles/virtual-filesystem-building-a-linux-filesystem-from-an-ordinary-file

Я провел небольшой сравнительный анализ операций записи в устройстве с обратной связью. Вот вывод:

• Если вы синхронизируете после каждой записи, то устройство с обратной связью работает значительно хуже (почти в два раза медленнее).
• Если вы разрешите кэш-памяти планировщика ввода-вывода выполнять свою работу, то вряд ли будет какая-либо разница между использованием устройства с обратной связью и прямым доступом к диску.

Результаты тестов

Сначала я запустил эталонный тест на устройстве с обратной связью в tmpfs 8 ГБ и на устройстве с обратной связью в этом устройстве с обратной связью ( с синхронизацией после каждой операции записи ):

ext4 в tmpfs:

Measured speed: 557, 567, 563, 558, 560, 559, 556, 556, 554, 557
Average speed : 558.7 MB/s  (min 554  max 560)

ext4 в extf в tmpfs:

Measured speed: 296, 298, 295, 295, 299, 297, 294, 295, 296, 296
Average speed : 296.1 MB/s  (min 294  max 299)

Очевидно, что существует некоторая разница в производительности при использовании устройств с обратной связью с синхронизацией при записи.
Затем я повторил тот же тест на моем жестком диске.
ext4 (HDD, 1000 МБ, 3 раза):

Measured speed: 24.1, 23.6, 23.0
Average speed : 23.5 MB/s  (min 23.0  max 24.1)

ext4 в ext4 (HDD, 945 МБ):

Measured speed: 12.9, 13.0, 12.7
Average speed : 12.8 MB/s  (min 12.7  max 13.0)

Тот же тест на жестком диске, теперь без синхронизации после каждой записи ( time (dd if=/dev/zero bs=1M count=1000 of=file; sync)измеряется как <size>/ <time in seconds>).
ext4 (HDD, 1000 МБ):

Measured speed: 84.3, 86.1, 83.9, 86.1, 87.7
Average speed : 85.6 MB/s  (min 84.3  max 87.7)

ext4 в ext4 (HDD, 945 МБ):

Measured speed: 89.9, 97.2, 82.9, 84.0, 82.7
Average speed : 87.3 MB/s  (min 82.7  max 97.2)

(как ни удивительно, тест обратной петли выглядит лучше, чем тест сырой диск, предположительно из-за меньшего размера устройства обратной петли, таким образом, меньше времени тратится на фактическую синхронизацию с диском)

Настройка бенчмарка

Сначала я создал петлевую файловую систему 8G в моем / tmp (tmpfs):

truncate /tmp/file -s 8G
mkfs.ext4 /tmp/file
sudo mount /tmp/file /mnt/
sudo chown $USER /mnt/

Затем я установил базовый уровень, заполнив подключенный файл обратной петли данными:

$ dd if=/dev/zero bs=1M of=/mnt/bigfile oflag=sync
dd: error writing '/mnt/bigfile': No space left on device
7492+0 records in
7491+0 records out
7855763456 bytes (7.9 GB) copied, 14.0959 s, 557 MB/s

После этого я создал еще одно петлевое устройство в предыдущем петлевом устройстве:

mkdir /tmp/mountpoint
mkfs.ext4 /mnt/bigfile
sudo mount /mnt/bigfile /tmp/mountpoint
sudo chown $USER /tmp/mountpoint

И снова провел тест 10 раз:

$ dd if=/dev/zero bs=1M of=/tmp/mountpoint/file oflag=sync
...
7171379200 bytes (7.2 GB) copied, 27.0111 s, 265 MB/s

а затем я размонтировал тестовый файл и удалил его:

sudo umount /tmp/mountpoint
sudo umount /mnt

(аналогично для испытания на HDD, за исключением того, я также добавил , count=1000чтобы предотвратить испытание от наполняя мой диск)
(и не пишущие-на-синхронизация теста, я побежал рассчитал ddи syncоперацию)

У меня не было проблем. Это все было твердо. Кэш файловой системы и планировщик ввода-вывода в Linux достаточно разумны, чтобы не было никакой заметной разницы между запросом диска напрямую и запросом раздела файла на диске.