lkml.org 
[lkml]   [1999]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] pagecache-2.3.9-H3, bmap & ext2fs cleanup patch

On Sat, 26 Jun 1999, Linus Torvalds wrote:

> > oh, i see. (i was used to setting this in the fs, this is why i missed it)
> > I think encoding holes in this way is bad, it will prevent legitimate uses
> > of the very same bit-combination: (!Mapped && Uptodate) will be useful if
> > we'll ever do 'delayed allocation' of filesystem blocks, it will represent
> > pretty ordinary blocks which are not yet mapped to the filesystem.
>
> Give me one valid reason to ever do that, please..
>
> There isn't. The _only_ thing "!Mapped && Uptodate && !Dirty" can mean is
> a hole.
>
> I agree that we might some day want to have buffers "Uptodate && Dirty"
> that haven't been mapped yet, but that is not a hole, that's just a
> delayed write. So let me modify my original claim to be that "Hole" is
> useless, because it is exactly the same as
>
> "!Mapped && !Dirty && Uptodate"
>
> Ok?

i think this is just playing tricks with _currently_ invalid
bitcombinations. !Mapped && Uptodate && !Dirty can be a valid combination
in the future as well - we might want to destroy buffer-heads (the
mapping) under a data block for legitimate reasons, eg. in the future it
might be possible to move the device under a filesystem, or we simply have
a filesystem with nonpermanent mappings, eg. a filesystem might choose to
destroy the mapping after the IO has been finished. (because it does
load-balancing or whatever) I agree that it's not used now, and it might
even never happen, but 'mapping' and 'cache state' are two different
things and the above looks unrobust (to me). We might as well go back to
!b_blocknr, thats a currently invalid state combination as well.

so we will just end up looking for more unused bit combinations, just to
express a completely unrelated _mapping_ concept: holes. Holes are not
'not mapped, uptodate, not dirty' data blocks, holes are a _mapping_
concept, a special abbreviation for pre-defined data content. We might
want to introduce a special device for holes... [now that devices are
officially part of the 'mapping' entity - i very much agree with that
change!] is that acceptable? It's also cheaper to test for it.

Ingo


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

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.084 / U:0.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site