> - BH_Hole is not in fact useful. It's an added state with no meaning,
> because it can _always_ be seen as
>
> !BH_Mapped && BH_Uptodate
>
> and as such adding it as a new bit only implies coherency problems
> without actually adding any information. Drop it..
in my patch even holes are BH_Mapped, thats the difference. I think these
are the correct state bits:
block mapping state:
b_blocknr: on-disk location of the block
BH_Hole: shortcut 'special' mapping, all zeros. [we could have
other special mappings as well.]
BH_Mapped: does (b_blocknr, BH_Hole) represent the
logical->physical mapping between inode block and
physical block. [we keep unmapped bhs around for
partial writes]
_iff_ a mapping is established, the following bits describe the data
block caching state:
data cache state bits:
BH_Uptodate: is in-memory content 'younger' than on-disk content.
[can be equal]
BH_Dirty: is in-memory data is strictly younger.
BH_New: on-disk data is invalid.
[these three would be slightly redundant if they represented an eg. CPU
cache, but an IO cache also has to deal with error handling.]
So i think there is _no_ real relation between BH_Mapped and the caching
state bits, apart from the fact that currently we first establish the
mapping and then start off with !BH_Uptodate !Dirty.
(the use of these bits might be currently used inconsistenty in a few
places, but this was the thinking behind it.)
_currently_ i agree that we might encode BH_Hole as an otherwise invalid
combination of state-bits, but i think this is dangerous. Eg. if we want
to do the 'delayed write' stuff [to allocate on-disk blocks only when a
block is being written out], then (Uptodate && !Mapped) will be a valid
combination: it means that the mapping towards the disk (filesystem) is
not yet established, but in-memory contents are valid and (obviously) more
recent than on-disk contents.
> I also think that trying to optimize the hole thing is futile. It adds
> complexity without gaining you anything in real life. You'd get a few
> really cool benchmark results, but no real speedup, and you'd have a
> kernel with extra rules just to try to keep them sane.
i agree that exporting it into the VM space is much ado for nothing.
Doing it in the buffer-cache layer is rather cheap though. [and we already
do it]
-- mingo
-
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/