Date: Fri, 28 Mar 2008 23:16:34 +0100 From: Max Laier <max@love2party.net> To: freebsd-stable@freebsd.org Cc: Ivan Voras <ivoras@freebsd.org> Subject: Re: Question about file system checks Message-ID: <200803282316.34595.max@love2party.net> In-Reply-To: <fsjp7l$4ov$1@ger.gmane.org> References: <47EBA3AB.40307@infracaninophile.co.uk> <47EC9245.6060200@infracaninophile.co.uk> <fsjp7l$4ov$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 28 March 2008 22:50:39 Ivan Voras wrote: > Matthew Seaman wrote: > > Ivan Voras wrote: > >> 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. > >> 6. ZFS crashed the kernel at least once. > > > > Hmmm.... in many ways a corrupt or truncated file is a worse outcome > > than a completely missing file -- at least if the file has gone away > > you know you've got to do something to fix it. A damaged file could > > end up silently causing weird behavioural effects and (by the law of > > natural cussedness) it is almost bound not to be tracked down until > > the day after the last good copy on the backup tapes gets > > overwritten... > > > > How do the different filesystems compare if you total all lost, > > damaged or truncated files? > > The only things that happen are that XFS and JFS get disproportionally > bad numbers and that ext3 gets almost identically bad results with > UFS+SU. Overall ratios remain approximately the same. > > To put this into perspective, for total "bad" files this means that, > e.g. UFS+SU created 20000 files, of which 750 were in some way "bad", > and ZFS created 46000 files, of which 900 were bad (so percentage is in > favour of ZFS). JFS created 43000 files of which 20000 were of wrong > size, but only 45 were completely lost. How bad this is depends, of > course on what is done with the file system. > > A big surprise for me was that Windows' NTFS did very good, though it > was the slowest in most other tests (which are smarter and probably use > fsync a lot), it managed to create 32000 files and have only 121 "bad" > in some way. Can you please give more details about your benchmark? It seems to me that the only thing you are measuring is how many files you managed to touch between the last sync(2) and plugging the power. This is not an interesting number. What would be interesting is to stop the syncer, touch a known number of files and then pull the plug. But in the end it boils down to: There is fsync to build transactions - use it or else. If you find that you lose fsync'ed files, that's a reason for concern, of course. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200803282316.34595.max>