From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 04:00:29 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 CE91D1065692 for ; Mon, 29 Sep 2008 04:00:29 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id 72F998FC23 for ; Mon, 29 Sep 2008 04:00:27 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA02.westchester.pa.mail.comcast.net with comcast id LSNX1a00E16LCl052U06nJ; Mon, 29 Sep 2008 04:00:06 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA06.westchester.pa.mail.comcast.net with comcast id LU0R1a0044v8bD73SU0Si7; Mon, 29 Sep 2008 04:00:27 +0000 X-Authority-Analysis: v=1.0 c=1 a=TxirYYpeSEAA:10 a=QO6ccaido9wA:10 a=QycZ5dHgAAAA:8 a=COaGVwIvTU2Pl52jQzUA:9 a=J5xvyeqAWYfK_SmOJXgFz2UJhGYA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 6BEE4C9437; Sun, 28 Sep 2008 21:00:25 -0700 (PDT) Date: Sun, 28 Sep 2008 21:00:25 -0700 From: Jeremy Chadwick To: Zaphod Beeblebrox Message-ID: <20080929040025.GA97332@icarus.home.lan> References: <20080921213426.GA13923@0lsen.net> <20080921215203.GC9494@icarus.home.lan> <20080921215930.GA25826@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Derek Kuli?ski , freebsd-stable@freebsd.org, Clint Olsen , pjd@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY 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: Mon, 29 Sep 2008 04:00:29 -0000 On Sun, Sep 28, 2008 at 11:30:01PM -0400, Zaphod Beeblebrox wrote: > On Sat, Sep 27, 2008 at 3:37 AM, Derek Kuli?ski wrote: > > > > > > ZFS is the first filesystem, to my knowledge, which provides 1) a > > > reliable filesystem, 2) detection of filesystem problems in real-time or > > > during scrubbing, 3) repair of problems in real-time (assuming raidz1 or > > > raidz2 are used), and 4) does not need fsck. This makes ZFS powerful. > > > > While I am very enthusiastic about ZFS (and use it for certain tasks), there > are several things preventing me from recommending it as a general-purpose > filesystem (and none of them are specific to FreeBSD's port of it). > > As a large NAS filestore, ZFS seems very well designed. That is, if the > goal is to store a very large amount of files with data integrity and serve > them up over the network, ZFS achieves it with aplomb. > > However, as a core general purpose filesystem, it seems to have flaws, not > the least of which is a re-separation of file cache and memory cache. This > virtually doesn't matter for a fileserver, but is generally important in a > general purpose local filesystem. ZFS also has a transactional nature --- > which probably, again, works well in a fileserver, but I find (as a local > filesystem) it introduces unpredicable delays as the buffer fills up and > then gets flushed en masse. I'm curious to know how Solaris deals with these problems, since the default filesystem (AFAIK) in OpenSolaris is now ZFS. CC'ing pjd@ who might have some insight there. > This is not to say that general purpose filesystems couldn't head in the ZFS > direction, or that ZFS is anthing but an amazing piece of technology, but > UFS and UFS+SU have not outlived their usefulness yet. > > Maybe support for odd block sizes in UFS would allow geom to manufacture > checksums (by subtracting their size from the source block). This would be > the last link in the chain to provide gjournal + gmirror + gchecksum > (addressing points 1, 2, 3 and 4). Equally, maybe gchecksum could work like > gjournal. Dunno --- that would probably be expensive in io ops. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |