Linux-kernel mailing list archive 1999-25,: Re: [patch] pagecache-2.3.9-H3, bmap & ext2fs cleanup patch

# Re: [patch] pagecache-2.3.9-H3, bmap & ext2fs cleanup patch

Ingo Molnar (mingo@chiara.csoma.elte.hu)
Sat, 26 Jun 1999 20:39:38 +0200 (CEST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Thomas Speck: "Re: modutils-2.2.0"
- Previous message: Alexander Viro: "Re: Extended f_count patch (SMP-safe handling of struct file)"

On Sat, 26 Jun 1999, Linus Torvalds wrote:

> - 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/

- Next message: Thomas Speck: "Re: modutils-2.2.0"
- Previous message: Alexander Viro: "Re: Extended f_count patch (SMP-safe handling of struct file)"