Messages in this thread | | | Date | Sun, 12 Dec 1999 21:17:57 -0500 (EST) | From | Alexander Viro <> | Subject | Re: invalidate inode given block? |
| |
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/
| |