Hi,
Looking at the following code of generic_file_write(), in 2.4, it
looks like there is a hidden assumption on the behavior of
prepare_write() and commit_write() about the behaviour of the file
system specific prepare_write() and commit_write() functions.
do {
.....
kaddr = kmap(page);
status = mapping->a_ops->prepare_write(file, page, offset, offset+bytes);
if (status)
goto sync_failure;
page_fault = __copy_from_user(kaddr+offset, buf, bytes);
flush_dcache_page(page);
status = mapping->a_ops->commit_write(file, page, offset, offset+bytes);
if (page_fault)
goto fail_write;
if (!status)
status = bytes;
if (status >= 0) {
written += status;
count -= status;
pos += status;
buf += status;
}
unlock:
kunmap(page);
/* Mark it unlocked again and drop the page.. */
SetPageReferenced(page);
UnlockPage(page);
page_cache_release(page);
if (status < 0)
break;
} while (count);
done:
......
Since the data is copied to the page after prepare_write() returns, it
seems that the assumption is that prepare_write() is synchronous and
the page was already read into memory in case it was not there.
Also, after commit_write(), the code immediately falls through unlock
which unlocks the page. Since a page is locked during IO, it seems
that commit_write() is synchronous and the page was already written
when it returns.
Can anyone clarify if these two assumptions are correct? if not, where
are we misinterpreting the code?
Regards,
Muli Ben-Yehuda,
Avi Teperman
Hi,
On Mon, 17 Feb 2003, Muli Ben-Yehuda wrote:
> Since the data is copied to the page after prepare_write() returns, it
> seems that the assumption is that prepare_write() is synchronous and
> the page was already read into memory in case it was not there.
prepare_write tells the fs which part of the page is overwritten, since
the data is usually managed in buffer sized chunks and if the write is
misaligned, it's needed to read a buffer from disk, so a complete buffer
can be written back. That read is indeed syncronous.
> Also, after commit_write(), the code immediately falls through unlock
> which unlocks the page. Since a page is locked during IO, it seems
> that commit_write() is synchronous and the page was already written
> when it returns.
The write is asynchronous, so the actual IO is started later. commit_write
only marks the written buffers as dirty.
bye, Roman