On Sat, Sep 27, 2008 at 3:37 AM, Derek Kuliński <[EMAIL PROTECTED]> 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.
_______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"