Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 28 Mar 2008 06:37:57 +0000
From:      Matthew Seaman <m.seaman@infracaninophile.co.uk>
To:        Ivan Voras <ivoras@freebsd.org>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: Question about file system checks
Message-ID:  <47EC9245.6060200@infracaninophile.co.uk>
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
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig90788590720304798A660920
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Ivan Voras wrote:
> Danny Pansters wrote:
>=20
>> Generally I can say that with freebsd even if you pull the plug and=20
>> then let it reboot and do the automatical background fsck you'll=20
>> likely loose only that one file you might have been editing while (or =

>> just before) you unplugged the box.
>=20
> Stress testing I've done suggests otherwise :) I've literally repeatedl=
y=20
> pulled the plug of a server in a controlled environment, and with a=20
> 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=
=20
> of UFS+SU especially directories), than any of: jfs, xfs, reiser3 (on=20
> Linux 2.6.22) and NTFS (on Windows 2003 Server). ext3 is somewhat=20
> similar to UFS+SU, though about 30% better at not loosing files.
>=20
> Some other notes from this proceeding:
>=20
> 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 =

> 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=20
> benchmark so this is a low-quality observation), closely followed by JF=
S=20
> 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...

How do the different filesystems compare if you total all lost, damaged
or truncated files?

	Cheers,

	Matthew

--=20
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW


--------------enig90788590720304798A660920
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.8 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkfskkwACgkQ8Mjk52CukIwuyACfYZM+tJP/tKIm+xEsoZOpDLhe
vwsAnRunRIGu37irlhehoZx4i6k6bjRQ
=MA74
-----END PGP SIGNATURE-----

--------------enig90788590720304798A660920--



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