Date: Fri, 28 Mar 2008 22:50:39 +0100 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-stable@freebsd.org Subject: Re: Question about file system checks Message-ID: <fsjp7l$4ov$1@ger.gmane.org> In-Reply-To: <47EC9245.6060200@infracaninophile.co.uk> References: <47EBA3AB.40307@infracaninophile.co.uk> <f9ae3129fa235b31251ec97bc12c1e78@localhost> <200803280029.08136.danny@ricin.com> <fshdv1$jbt$1@ger.gmane.org> <47EC9245.6060200@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1E9CE1C7244DC37F22202605 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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=20 >> (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= =20 >> or of unexpected length (40%-50%!) >> 4. In no case has any of the above file systems gone completely=20 >> 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=20 >> files during this benchmark (though speed was not the target for this = >> benchmark so this is a low-quality observation), closely followed by=20 >> JFS and XFS. >> 6. ZFS crashed the kernel at least once. >> >=20 > 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... >=20 > 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=20 bad numbers and that ext3 gets almost identically bad results with=20 UFS+SU. Overall ratios remain approximately the same. To put this into perspective, for total "bad" files this means that,=20 e.g. UFS+SU created 20000 files, of which 750 were in some way "bad",=20 and ZFS created 46000 files, of which 900 were bad (so percentage is in=20 favour of ZFS). JFS created 43000 files of which 20000 were of wrong=20 size, but only 45 were completely lost. How bad this is depends, of=20 course on what is done with the file system. A big surprise for me was that Windows' NTFS did very good, though it=20 was the slowest in most other tests (which are smarter and probably use=20 fsync a lot), it managed to create 32000 files and have only 121 "bad"=20 in some way. --------------enig1E9CE1C7244DC37F22202605 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH7Wg1ldnAQVacBcgRAmjbAKDzp/IlmftyDo3LWDPIiPs7j/4SbgCg5FRs A2Q0CXP+z13tg+OjnJy+RZ0= =2u9D -----END PGP SIGNATURE----- --------------enig1E9CE1C7244DC37F22202605--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fsjp7l$4ov$1>