On Sat, 9 Jun 2001, Trond Myklebust wrote:
> >>>>> " " == Alexander Viro <[EMAIL PROTECTED]> writes:
>
> > That has nothing to ->lookup(). If it picks an existing inode -
> > it has no business changing it. If it creates a new one -
> > there's nobody else to touch it while we are filling the
> > thing. _If_ you do filling the inode after it's hashed and rely
> > on BKL - that's a bug waiting to happen that needs to be fixed.
>
> Wrong. This is done routinely on all networked filesystems. It has to
> be - only the server has full up to date knowledge of those values
> (unless the protocol happens to support delegation).
> On these filesystems, you want to ensure that updates don't screw up
> the tests and local changes in the generic read and write code in
> mm/filemap.c (amongst other things) and hence all calls into
> generic_file_* are also protected by the BKL.
What the hell does it have to ->lookup()? And in any case,
BKL on generic_file_* is a huge overkill. You need to protect what?
->i_size? And for that you take BKL over a huge chunk of code, 99%
of which doesn't give a damn for i_size?
What we ought to do in 2.5.early (possibly - in 2.4) is to
add ->max_page to address_space. I.e. ->i_size in pages. Then
the latter becomes private to fs and the former is automatically
atomic (all changes are under i_sem and read vs. assign is OK
since it's int; the only problem with i_size is in partial update of
64bit value seen by reader).
Yes, in principle we can get stray get_block() in
block_read_full_page(). However, it's harmless when change
was from ->commit_write() (for obvious reasons) and it's
harmless when change was from vmtruncate() (we already had
the page locked, so vmtruncate() will wait until IO is over).
->commit, ->prepare and vmtruncate() are serialized by
->i_sem.
->writepage() is a mess, but that's a separate story - we can
get temporary writes past the EOF in the beginning of vmtruncate(),
but it will wait for their completion and wipe them out. Moderately
nasty, but not too urgent. In the worst case we get stray data past
the EOF if we get crash at the wrong time. Again, the right fix is
to add ->max_page.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
