[lkml]   [2007]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/1][RFC] mm: prepare_write positive return value
On Tue, 06 Feb 2007 11:33:46 +0300
Dmitriy Monakhov <> wrote:

> Almost all read/write operation handles data with chunks(segments or pages)
> and result has integral behaviour for folowing scenario:
> for_each_chunk() {
> res = op(....);
> if(IS_ERROR(res))
> return progress ? progress : res;
> progress += res;
> }
> prepare_write may has integral behaviour in case of blksize < pgsize,
> for example we successfully allocated/read some blocks, but not all of them,
> and than some error happend. Currently we eliminate this progress by doing
> vmtrunate() after prepare_has failed.
> It is good to have ability to signal about this progress. Interprete positive
> prepare_write() ret code as bytes num that fs ready to handle at this moment.
> I've ask SAW, he think it is sane. This size always less than PAGE_CACHE_SIZE
> so it less than AOP_TRUNCATED_PAGE too.
> BTH: This approach was used in OpenVZ 2.6.9 kernel in order to make FS with
> delayed allocation more correct, and its works well.
> I think not everybody will happy about this, but let's discuss all advantages
> and disadvantages of this change.

That seems to be a logical change. We'd need to review all the callers and
callees to make sure that they handle this change correctly.

Your changes deviate quite a lot from standard kernel coding style. Please fix

Please cc on the next version of these patches. I'm
seriously running out of bandwidth over here and ext4 has other maintainers.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-02-07 00:43    [W:0.042 / U:1.724 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site