--On 09/12/00 10:47:23 -0400 Alexander Viro <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 12 Sep 2000, Chris Mason wrote:
>
>> --On 09/12/00 10:30:28 -0400 Alexander Viro <[EMAIL PROTECTED]> wrote:
>>
>> >
>> >
>> > On Tue, 12 Sep 2000, Chris Mason wrote:
>> >
>> >> Almost, truncate could remove the file items in the middle of the
>> >> unmerge.
>> >>
>> >> proc1: writepage->prepare_write->unmerge
>> >
>> > Chris, RTFPOSIX. pageout should _never_ expand the file. _If_ you are
>> > using ->prepare_write() in ->writepage() at all (you don't have to) it
>> > should go only up to ->i_size, or you've got much more serious
>> > problems.
>> >
>> > IOW, ->writepage() has no business unmerging anything.
>> >
>>
>> Yes, another option is to have writepage go directly into the tail (as
>> said in the other posts). With or without the unmerge, it is still a
>> concurrency issue, the point was the tail can go away in the middle of a
>> writepage.
>
> Check vmtruncate(). It will start with setting ->i_size and that should
> stop any new attemtps of writepage(). Then it will acquire (and release)
> page locks on all in-core pages that go beyond the new ->i_size, thus
> waiting for completion of all page operations that began earlier. Only
> after that it calls ->truncate(). See how it works? That's the reason why
> on shrinking truncate() ->i_size *must* be set before the method call.
>
Thanks, that's the part I was missing...
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
