From owner-freebsd-stable@FreeBSD.ORG Fri Mar 28 22:01:55 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 60812106566C; Fri, 28 Mar 2008 22:01:55 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4DF2E8FC1D; Fri, 28 Mar 2008 22:01:55 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 29E831A4D83; Fri, 28 Mar 2008 15:01:55 -0700 (PDT) Date: Fri, 28 Mar 2008 15:01:55 -0700 From: Alfred Perlstein To: Ivan Voras Message-ID: <20080328220155.GZ67856@elvis.mu.org> References: <47EBA3AB.40307@infracaninophile.co.uk> <200803280029.08136.danny@ricin.com> <47EC9245.6060200@infracaninophile.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org 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:01:55 -0000 * Ivan Voras [080328 14:51] 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. > I know this sounds pretty awful, but honestly any file modified within an hour and not fsync'd being "lost" is not really a bad thing. It's pretty much "the unix way" that only fsync'd files/directories or file modified more than several minutes ago are safe. -- - Alfred Perlstein