On Fri, 25 May 2001, Linus Torvalds wrote:
> If somebody can show that the above is worth it and worth implementing (ie
> the Al Viro kind of "I have a real-life schenario where I'd like to use
> it"), and implements it (should be a fairly trivial exercise), then I'll
> happily accept new semantics like this.
OK, here's a real-world scenario: inode table on 1Kb ext2 (or 4Kb on
Alpha, etc.) consists of compact pieces - one per cylinder group.
There is a natural mapping from inodes to offsets in that beast.
However, these pieces can trivially be not page-aligned. readpage()
on a boundary of two pieces means large seek.
Another example (even funnier) is bitmaps. Same story, but here you can
have 1Kb per cylinder group. Which is 8Mb in that case. I.e. on Alpha
it means that readpage() will require 7 seeks, 8Mb each. And the worst
thing being, unless we have corrupted free inodes counters we _will_
find what we need in the first 1Kb chunk we are looking at.
I can easily give more examples - just ask. BTW, the fact that this stuff
is so fragmented is not a bug - we want it evenly spread over disk, just
to have the ability to allocate a block/inode not too far from the piece
of bitmap we'll need to modify.
Al
PS: Uff... OK, looking at the locking stuff in fs/super.c was useful - I've
found a way to do it that is seriously simpler than what I used to do.
Just let me torture it for a couple of hours - so far it looks fine...
-
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/
This archive was generated by hypermail 2b29 : Thu May 31 2001 - 21:00:24 EST