--On 09/12/00 10:17:29 -0400 Alexander Viro <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 12 Sep 2000, Daniel Phillips wrote:
>
>> Chris Mason wrote:
>> > > Now I can unmerge this way:
>> > >
>> > > - Fix up various inode fields
>> > > - getpage the tail page from the mapping
>> > > - bread the shared tail block
>> > > - get the appropriate page buffer using page_buffer
>> > > - copy the tail fragment to that buffer and dirty it
>> > >
>> > > I can do this at a high level - the place where the unmerge
>> > > conditions are most easily and accurately detected - as opposed to
>> > > deep in the guts of the page I/O. The page is left in a state that
>> > > already makes sense to read_page, write_page and friends.
>> >
>> > Sorry, I don't see how this saves you from the file size changing in
>> > file_write or truncate. While you are breading the tail, file_write
>> > might be trying to unmerge it.
>>
>> But this *is* unmerge. Clearly, I can't allow two unmerges at the
>> same time on the same file. I haven't gotten to the locking yet, but
>> this *must* be enforced one way or another.
>
> Do it in ->prepare_write() if page is the last one. End of story. You'll
> have to call the thing in your truncate() (expanding case) and that's it.
> Pageout _never_ changes the file size, write and truncate own the ->i_sem.
> So "page covers the end of file" is not going to change under you when you
> are interested in unmerging. Here's your serialization.
>
Almost, truncate could remove the file items in the middle of the unmerge.
proc1: writepage->prepare_write->unmerge
proc2: truncate()
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
