Messages in this thread | | | Date | Wed, 25 Oct 2000 14:15:05 -0600 | From | "Jeff V. Merkey" <> | Subject | Re: PATCH: killing read_ahead[] |
| |
Alexander Viro wrote: > > On Wed, 25 Oct 2000, Jeff V. Merkey wrote: > > > Al, > > > > Thanks. I'll print this one out and post it on the wall for tonight's > > debugging session. > [snip] > > > (e.g. generic_commit_write have to mess with i_size value to update the > ^^^^^^^ > Ugh. s/have/doesn't have/, indeed. Sorry.
Wrong syntax:
:%s/have/doesn't have/gc
:-)
> > As for tonight's debugging session... I love your optimism, but I would > really like to see comments from Linus. For one thing, patch intersects > with Rik's one, so I wouldn't expect that to be over tonight (and that's > completely aside of the chances that Linus will say "no" to that idea). > Linus? > > ObDevices: the last time when we were talking about the devices-in-pagecache > the things stopped on the ->i_size accesses and related ugliness. IMO the > main reason of that ugliness was in the attempts to _move_ the i_size to > address_space. Which was a patently bad idea. How about mirroring it > there? Notice that atomicity is not an issue - we don't have it when we > set/modify long long anyway. Said that, I really think that caching the > values of these expressions makes sense regardless of device handling.
In reality, the file has already been extended in prepare_write() and the fs's should always make this assumption. If the write fails, it should be treated as an I/O error. i_size should be assumed to have been extended at this point (since the space on the device has already been allocated.
The way aroud this is to enforce i_size updates in prepare_write() (this is where I return, "out of space" return codes, and the other FS's would probably be ok with some minor changes.).
:-)
Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |