В недавней теме про дефрагментатор ext4 iZEN начал доказывать, что FreeBSD'шная UFS2 не подвержена фрагментации. Т.е. как-бы вообще. Я решил попробовать доказать обратное путём экспериментирования со свежескачанным LiveCD Frenzy (основан на FreeBSD 8.0). В результате эксперимента мне удалось выяснить, что FreeBSD'шный fsck заместо степени фрагментации показывает непонятно что...
Для начала надо определиться, что же такое фрагментация. (Далее идёт описание моего понимания этого термина, если что-то не так - поправьте меня). Допустим есть три файла - 1, 2 и 3, каждый из них имеет длину 10. При отсутствии фрагментации на блочном устройстве они должны быть расположены так: 111111111122222222223333333333. Если фрагментация имеет место, то может получиться что-то вроде: 123123123123123123123123123123. В худшем случае части файлов будут не только перепутаны между собой, но ещё и расположены в обратном порядке. Я думаю не надо объяснять почему это плохо - при последовательном чтении файла получается непоследовательное чтение блочного устройства. Задача дефрагментатора - расположить части файлов последовательно и в правильном порядке, т.е. сделать 123123123123123123123123123123 -> 111111111122222222223333333333. Надеюсь я правильно написал?
А теперь про эксперименты над Frenzy.
[root@frenzy ~]# uname -a
FreeBSD frenzy 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Thu Jan 7 11:59:02 UTC 2010 root@frenzy.home.local:/buildscripts/frenzybuild/build/buildscripts/frenzybuild/src/sys/FRENZY i386
[root@frenzy ~]# dd if=/dev/zero of=fsimage bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes transferred in 1.333509 secs (100650038 bytes/sec)
[root@frenzy ~]# mdconfig -a -t vnode -f fsimage
md3
[root@frenzy ~]# newfs /dev/md3
/dev/md3: 128.0MB (262144 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 32.02MB, 2049 blks, 4160 inodes.
super-block backups (for fsck -b #) at:
160, 65728, 131296, 196864
[root@frenzy ~]# mkdir ufs2
[root@frenzy ~]# mount /dev/md3 ufs2
[root@frenzy ~]# fsck -n -t ufs md3 | grep fragmentation
2 files, 2 used, 63349 free (21 frags, 7916 blocks, 0.0% fragmentation)
[root@frenzy ~]# for ((i=0; i<1000; i++)); do dd if=/dev/zero of=/root/ufs2/test$i bs=1k count=120; done
... вывод пропущен ...
[root@frenzy ~]# df -h | grep ufs
/dev/md3 124M 117M -3.4M 103% /root/ufs2
[root@frenzy ~]# fsck -n -t ufs md3 | grep fragmentation
1002 files, 60009 used, 3342 free (998 frags, 293 blocks, 1.6% fragmentation)
[root@frenzy ~]# rm ufs2/test*0
[root@frenzy ~]# df -h | grep ufs2
/dev/md3 124M 105M 8.3M 93% /root/ufs2
[root@frenzy ~]# fsck -n -t ufs md3 | grep fragmentation
902 files, 54009 used, 9342 free (1206 frags, 1017 blocks, 1.9% fragmentation)
[root@frenzy ~]# cat /dev/zero >>ufs2/fragmented
/root/ufs2: write failed, filesystem is full
cat: stdout: No space left on device
[root@frenzy ~]# fsck -n -t ufs md3 | grep fragmentation
903 files, 61697 used, 1654 free (1206 frags, 56 blocks, 1.9% fragmentation)
[root@frenzy ~]# rm ufs2/test*1
[root@frenzy ~]# cat /dev/zero >>ufs2/fragmented
/root/ufs2: write failed, filesystem is full
cat: stdout: No space left on device
[root@frenzy ~]# fsck -n -t ufs md3 | grep fragmentation
803 files, 55697 used, 7654 free (982 frags, 834 blocks, 1.6% fragmentation)
- UFS2 не обладает телепатией и не могла изначально расположить мелкие файлы так, чтобы при их непоследовательном удалении место на блочном устройстве освобождалось последовательно
- UFS2 в фоне не перемещает части существующих файлов, т.е. не делает фоновую дефрагментацию
, то куски файла на блочном устройстве должны быть расположены не последовательно, т.е. он должен быть фрагментирован. Но что же мы видим:
[root@frenzy ~]# fsck -n -t ufs md3 | grep fragmentation
3 files, 63025 used, 326 free (14 frags, 39 blocks, 0.0% fragmentation)
А теперь вопрос: чем же смотреть фрагментацию во FreeBSD? Под линуксом с помощью утилиты filefrag можно посмотреть на сколько частей разбило файл.
