From owner-freebsd-stable@FreeBSD.ORG Fri Mar 28 22:18:27 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 D69F31065672 for ; Fri, 28 Mar 2008 22:18:27 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by mx1.freebsd.org (Postfix) with ESMTP id 6D98D8FC2F for ; Fri, 28 Mar 2008 22:18:27 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-009-190.pools.arcor-ip.net [88.66.9.190]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1JfMu13g1p-0000cY; Fri, 28 Mar 2008 23:18:26 +0100 Received: (qmail 92827 invoked from network); 28 Mar 2008 22:17:33 -0000 Received: from myhost.laiers.local (192.168.4.151) by router.laiers.local with SMTP; 28 Mar 2008 22:17:33 -0000 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org Date: Fri, 28 Mar 2008 23:16:34 +0100 User-Agent: KMail/1.9.9 References: <47EBA3AB.40307@infracaninophile.co.uk> <47EC9245.6060200@infracaninophile.co.uk> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803282316.34595.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+h/K4KBzb0NInldE/8nMKG5GGGPaqy/iKZZfO NuobGvPHad4Df7UXuFoJBdgDHe1VhqI0/z0OASMdph7R4J3oiW PaeHCv1w+dLH/e6z5haQg== Cc: Ivan Voras 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 22:18:27 -0000 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