Note that I mentioned io_map and that its implementation will not be helped at all by such a simple library. That includes large file support. Large filesystems might trivially be supported by such a library if it always accesses the store directly, without any mapping. No mapping however means no cache, and that's where your performance is saying good bye.
In addition, all these library functions are layered upon a block layer inefficiently. The block layer has a very small cache (8 blocks). You can increase block count, but the cache algorithm is optimized for small cache and will definately be very inefficient for larger caches. The library functions that need to use part of a block don't get pointer to the already cached block, but supply own buffer where the block layer will copy bytes from its cache. This means that there are _a lot_ of redundant memory copies.
This doesn't mean the library is bad. It's just optimized for e2fsck and other offline programs, like e2tools.
Regards -- Ognyan Kulev <[EMAIL PROTECTED],fsa-bg.org}> 7D9F 66E6 68B7 A62B 0FCF EB04 80BF 3A8C A252 9782
_______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
