Date: Sun, 28 Sep 2008 21:00:25 -0700 From: Jeremy Chadwick <koitsu@FreeBSD.org> To: Zaphod Beeblebrox <zbeeble@gmail.com> Cc: Derek Kuli?ski <takeda@takeda.tk>, freebsd-stable@freebsd.org, Clint Olsen <clint.olsen@gmail.com>, pjd@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY Message-ID: <20080929040025.GA97332@icarus.home.lan> In-Reply-To: <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <takeda@takeda.tk> 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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080929040025.GA97332>