In article <Pine.LNX.4.10.10005111711480.1319-100000@penguin.transmeta.com> you
wrote:
: Note that what you can always do is actually very simple:
: - _always_ use a sector size of 512 bytes.
: - allocate 8 sectors per 4kB page
: - fill in the sector numbers appropriately: if you have a 2kB "run", then
: you just fill in sector numbers X, X+1, X+2 and X+3 on the four buffer
: heads in question.
: - the ll_rw_block logic will all coalesce the writes back again, so the
: IO should still be done in 2kB blocks. But you'd have the option of
: just writing 512 bytes of them if you wanted to.
there's another way - get rid of the check in ll_rw_block() which forces
all buffers to be the same size as the declared blocksize of the device.
the lower layers don't care if you send them a bunch of buffers with different
sizes. I can't see any reason for that bit of code to exist other than
sanity checking. so far it's fine, since all our filesystems are block-based
and will do I/Os in blocks. but extent based filesystems would really like
to do variable sized I/Os.
: (And yes, it _will_ use slightly more CPU time, no question about that.
: However, most of the common operations are done on pages rather than on
: the buffers that are used to fill in the pages or write them back, so many
: of the higher-level IO abstractions won't even know the difference).
allocation/initialization/freeing of 8 buffer heads rather than 1,
ll_rw_block logic coalescing stuff which we already knew was contiguous,
sound like unnecessary overheads when you can get the same job done by
_removing_ code. unless it does something else which has escaped me.
of course it's easy for the filesystem to brew its own ll_rw_block(), since
all the stuff needed is exported.
ganesh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:20 EST