UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY

[Zaphod Beeblebrox]

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.

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.