Question about file system checks

[Dan Nelson]

In the last episode (Mar 28), Ivan Voras said:
> Danny Pansters wrote:
>> Generally I can say that with freebsd even if you pull the plug and
>> then let it reboot and do the automatical background fsck you'll
>> likely loose only that one file you might have been editing while
>> (or just before) you unplugged the box.
> 
> Stress testing I've done suggests otherwise :) I've literally
> repeatedly pulled the plug of a server in a controlled environment,
> and with a network logging of (a high load of) file system
> operations. My results show that UFS+SU and ZFS on FreeBSD loose *the
> most* files (and in case of UFS+SU especially directories), than any
> of: jfs, xfs, reiser3 (on Linux 2.6.22) and NTFS (on Windows 2003
> Server). ext3 is somewhat similar to UFS+SU, though about 30% better
> at not loosing files.

Note that you can tweak the SU caching time by adjusting the sysctls
kern.{meta,dir,file}delay.  Take them down to 10 seconds instead of 30
and you'll lose less files (at the cost of more disk I/O of course).
 
> Some other notes from this proceeding:
> 
> 1. UFS+gjournal looses the least, but it's also the slowest.
> 2. UFS+SU had no truncated files or files of unexpected length (apparently 
> it just looses the file that would end up in this state)
> 3. XFS and JFS end up with a *huge* number of files that are truncated or 
> of unexpected length (40%-50%!)
> 4. In no case has any of the above file systems gone completely corrupted 
> or lost any of the files/directories not being updated.
> 5. ZFS on FreeBSD was the fastest, in the sense of creating the most files 
> during this benchmark (though speed was not the target for this benchmark 
> so this is a low-quality observation), closely followed by JFS and XFS.

ZFS's transaction commit interval is only 5 seconds (see txg_time in
uts/common/fs/zfs/txg.c); how many more files/second did it create vs
the others to be able to lose the most files in that window? :)

> 6. ZFS crashed the kernel at least once.

-- 
	Dan Nelson
	dnelson at allantgroup.com