From owner-freebsd-stable@FreeBSD.ORG Fri Mar 28 21:51:04 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 304EC106566C for ; Fri, 28 Mar 2008 21:51:04 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id A50DA8FC19 for ; Fri, 28 Mar 2008 21:51:03 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JfMTP-00071A-Dz for freebsd-stable@freebsd.org; Fri, 28 Mar 2008 21:50:55 +0000 Received: from 89-172-61-54.adsl.net.t-com.hr ([89.172.61.54]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 28 Mar 2008 21:50:55 +0000 Received: from ivoras by 89-172-61-54.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 28 Mar 2008 21:50:55 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Fri, 28 Mar 2008 22:50:39 +0100 Lines: 70 Message-ID: References: <47EBA3AB.40307@infracaninophile.co.uk> <200803280029.08136.danny@ricin.com> <47EC9245.6060200@infracaninophile.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1E9CE1C7244DC37F22202605" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-61-54.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) In-Reply-To: <47EC9245.6060200@infracaninophile.co.uk> X-Enigmail-Version: 0.95.6 Sender: news Subject: Re: Question about file system checks X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2008 21:51:04 -0000 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--