Messages in this thread | | | Date | Sun, 6 May 2001 15:00:58 +1200 | From | Chris Wedgwood <> | Subject | Re: [PATCH] SMP race in ext2 - metadata corruption. |
| |
On Sun, May 06, 2001 at 04:50:01AM +0200, Andrea Arcangeli wrote:
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/
| |