Re: invalidate inode given block?

Alexander Viro (viro@math.psu.edu)
Sun, 12 Dec 1999 21:17:57 -0500 (EST)


On Mon, 13 Dec 1999, Peter T. Breuer wrote:

> Any of the above, eventually. All I might know is that a block on disk
> has changed, and yes, I see what you are on about. I will know that the
> changes are consistent from a file system point of view. They will have
> been caused by a file system operation in a remote computer miraculously
> sharing the same underlying device. There isn't a write mutex right
> now, but there will be. I'm just looking around to see if I can get
> away without communicating higher-level info.

Oh, my... Yes, I see what you are looking for, but... Without the
information about inode being modified - no. _If_ you are only after data
(not positional metadata) you can kinda-sorta kludge it up, but that will
take placing all bloody buffer_heads back into the cache and doing
pretty non-trivial synchronizations. For indirect blocks - forget it. For
references right in the inode - maybe, but little good it will do you,
considering the previous. For _anything_ in directories - hell, no. We are
holding to much state to allow anything like that.

For somewhat better approach you might consider passing the
<address_space, logical address> instead of <physical address>. That
might be more or less bearable. Especially combined with something a-la
leases.

> As a first approximation, say "contents of file". Your answer rather
> leads me to suppose that that at least is possible. (Being a good idea
> is another question).

It's not a question ;-/

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