UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY

[Jeremy Chadwick]

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 at 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 |