Moving e2fsck into the kernel is a completly different matter
than caching the blockdevice accesses with pagecache instead of
buffercache.
No, I was takling about user space fsck using character devices.
Solaris is one example.
I have no idea why/if other got rid of it completly, but the fact
block_dev is useful has nothing to do if it's in pagecache or in
buffercache, really.
I'm not claiming it is... what I'm asking is _why_ do we need block
devices once 'everything' lives in the page cache?
It's just that by doing it in pagecache you can mmap it as well
and it will provide overall better performance and it's probably
cleaner design. The only visible change is that you will be able
to mmap a blockdevice as well.
Why? What needs to mmap a block device? Since these are typically
larger than that you can mmap into a 32-bit address space (yes, I'm
ignoring the 5% or so of cases where this isn't true) I'm not aware
on many applications that do it.
Databases typically _want_ raw/character device access and do their
own buffering, I assume related applications also do.
About a kernel based fsck Alexander told me he likes it, I
personally don't care about it that much because I believe...
As I said, I'm not takling about kernel based fsck, although for
_VERY_ large filesystems even with journalling I suspect it will be
required one day (so it can run in the background and do consistency
checking when the machine is idle).
--cw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/