Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 28 Mar 2008 09:28:44 -0500
From:      Dan Nelson <dnelson@allantgroup.com>
To:        Ivan Voras <ivoras@freebsd.org>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: Question about file system checks
Message-ID:  <20080328142843.GD28690@dan.emsphone.com>
In-Reply-To: <fshdv1$jbt$1@ger.gmane.org>
References:  <47EBA3AB.40307@infracaninophile.co.uk> <f9ae3129fa235b31251ec97bc12c1e78@localhost> <200803280029.08136.danny@ricin.com> <fshdv1$jbt$1@ger.gmane.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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@allantgroup.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080328142843.GD28690>