All of lore.kernel.org
 help / color / mirror / Atom feed
* A question on block_prepare_write()
@ 2010-10-23 13:44 Namhyung Kim
  2010-10-23 17:40 ` Andrew Morton
  0 siblings, 1 reply; 4+ messages in thread
From: Namhyung Kim @ 2010-10-23 13:44 UTC (permalink / raw)
  To: linux-fsdevel; +Cc: LKML

Hello,

I see block_prepare_write() has local variable wait[2] to keep track of
buffer_heads which are not up-to-date. But I'm wondering how it could be
guaranteed there will be no more than 2 such buffer_heads? Is there any
restriction on the usage of the function? Using MAX_BUF_PER_PAGE instead
of the magic number 2 is just useless? I couldn't find any comments or
documentation on this.

Any of your comments would be greatly appreciated. TIA. :-)

-- 
Regards,
Namhyung Kim



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: A question on block_prepare_write()
  2010-10-23 13:44 A question on block_prepare_write() Namhyung Kim
@ 2010-10-23 17:40 ` Andrew Morton
  2010-10-23 18:00     ` Namhyung Kim
  0 siblings, 1 reply; 4+ messages in thread
From: Andrew Morton @ 2010-10-23 17:40 UTC (permalink / raw)
  To: Namhyung Kim; +Cc: linux-fsdevel, LKML

On Sat, 23 Oct 2010 22:44:42 +0900 Namhyung Kim <namhyung@gmail.com> wrote:

> Hello,
> 
> I see block_prepare_write() has local variable wait[2] to keep track of
> buffer_heads which are not up-to-date. But I'm wondering how it could be
> guaranteed there will be no more than 2 such buffer_heads? Is there any
> restriction on the usage of the function? Using MAX_BUF_PER_PAGE instead
> of the magic number 2 is just useless? I couldn't find any comments or
> documentation on this.
> 
> Any of your comments would be greatly appreciated. TIA. :-)
> 

block_prepare_write() may need to preread any buffer_head which are
being only partially modified by the write().

Buffers which aren't being modified at all don't need to be preread. 
Buffers which are being fully modified don't need to be preread
(because all their data is being overwritten).

page:                      |-----------------------|
buffer_heads:              |-----|-----|-----|-----|
area we're writing to:               |---------|

There can only be a maximum of two partially-modified buffers in the page.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: A question on block_prepare_write()
  2010-10-23 17:40 ` Andrew Morton
@ 2010-10-23 18:00     ` Namhyung Kim
  0 siblings, 0 replies; 4+ messages in thread
From: Namhyung Kim @ 2010-10-23 18:00 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-fsdevel, LKML

2010-10-23 (토), 10:40 -0700, Andrew Morton:
> On Sat, 23 Oct 2010 22:44:42 +0900 Namhyung Kim <namhyung@gmail.com> wrote:
> 
> > Hello,
> > 
> > I see block_prepare_write() has local variable wait[2] to keep track of
> > buffer_heads which are not up-to-date. But I'm wondering how it could be
> > guaranteed there will be no more than 2 such buffer_heads? Is there any
> > restriction on the usage of the function? Using MAX_BUF_PER_PAGE instead
> > of the magic number 2 is just useless? I couldn't find any comments or
> > documentation on this.
> > 
> > Any of your comments would be greatly appreciated. TIA. :-)
> > 
> 
> block_prepare_write() may need to preread any buffer_head which are
> being only partially modified by the write().
> 
> Buffers which aren't being modified at all don't need to be preread. 
> Buffers which are being fully modified don't need to be preread
> (because all their data is being overwritten).
> 
> page:                      |-----------------------|
> buffer_heads:              |-----|-----|-----|-----|
> area we're writing to:               |---------|
> 
> There can only be a maximum of two partially-modified buffers in the page.

I see. It considers both edges of the to-be-written data. Thanks for
your clear and kindly explanation. :-)


-- 
Regards,
Namhyung Kim



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: A question on block_prepare_write()
@ 2010-10-23 18:00     ` Namhyung Kim
  0 siblings, 0 replies; 4+ messages in thread
From: Namhyung Kim @ 2010-10-23 18:00 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-fsdevel, LKML

2010-10-23 (토), 10:40 -0700, Andrew Morton:
> On Sat, 23 Oct 2010 22:44:42 +0900 Namhyung Kim <namhyung@gmail.com> wrote:
> 
> > Hello,
> > 
> > I see block_prepare_write() has local variable wait[2] to keep track of
> > buffer_heads which are not up-to-date. But I'm wondering how it could be
> > guaranteed there will be no more than 2 such buffer_heads? Is there any
> > restriction on the usage of the function? Using MAX_BUF_PER_PAGE instead
> > of the magic number 2 is just useless? I couldn't find any comments or
> > documentation on this.
> > 
> > Any of your comments would be greatly appreciated. TIA. :-)
> > 
> 
> block_prepare_write() may need to preread any buffer_head which are
> being only partially modified by the write().
> 
> Buffers which aren't being modified at all don't need to be preread. 
> Buffers which are being fully modified don't need to be preread
> (because all their data is being overwritten).
> 
> page:                      |-----------------------|
> buffer_heads:              |-----|-----|-----|-----|
> area we're writing to:               |---------|
> 
> There can only be a maximum of two partially-modified buffers in the page.

I see. It considers both edges of the to-be-written data. Thanks for
your clear and kindly explanation. :-)


-- 
Regards,
Namhyung Kim


--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2010-10-23 18:00 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-23 13:44 A question on block_prepare_write() Namhyung Kim
2010-10-23 17:40 ` Andrew Morton
2010-10-23 18:00   ` Namhyung Kim
2010-10-23 18:00     ` Namhyung Kim

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.