Pagewriteback clarification

Pagewriteback clarification

[Sukadev Bhattiprolu]

Hi,

I have a couple of questions regarding PageWriteback flag and its
relationship to locked buffers and in-progress I/O in progress.
I would appreciate any input/pointers on this.

1.  Based on documentation in Documentation/filesystems/filesystems
    (LK 2.6.13), .writepage() can be called even if I/O is in progress
    for the page.  And if an I/O is in progress, PageWriteback is TRUE
    for the page.
    
    Then, can a filesystem's .writepage simply rely on PageWriteback flag
    to determine if I/O is currently in progress ? (ext3/reiser etc seem
    to use test_set_buffer_locked() to determine if I/O is in progress)
    
2. __block_write_full_page() has following lines of code:

    In a do..while() loop:

       if (wbc->sync_mode != WB_SYNC_NONE || !wbc->nonblocking) {
            lock_buffer(bh);
        } else if (test_set_buffer_locked(bh)) {
            redirty_page_for_writepage(wbc, page);
            continue;
        }

    and immediately after the loop is following BUG_ON().

        BUG_ON(PageWriteback(page));

    The test_set_buffer_locked(bh) appears to be testing for in-progress
    I/O and if TRUE redirties the page.

    But if a sync I/O is in progress for the page for instance, would
    PageWriteback not be TRUE ?

Thanks,

Sukadev

Re: Pagewriteback clarification

[Nikita Danilov]

Sukadev Bhattiprolu writes:
 > Hi,
 > 
 > I have a couple of questions regarding PageWriteback flag and its
 > relationship to locked buffers and in-progress I/O in progress.
 > I would appreciate any input/pointers on this.
 > 
 > 1.  Based on documentation in Documentation/filesystems/filesystems

Cannot find such file. Are you talking about
Documentation/filesystems/Locking?

 >     (LK 2.6.13), .writepage() can be called even if I/O is in progress
 >     for the page.  And if an I/O is in progress, PageWriteback is TRUE

No, callers of ->writepage() should assure that

 - page is locked, and

 - writeback bit is clear on that page.

Which means that no IO is going on against this page. When
Documentation/filesystems/Locking talks about "currently-in-progress
I/O" it means any IO going to or fro the device, and "blocking against
in-progress I/O" means blocking due to device queue congestion.

Nikita.

Re: Pagewriteback clarification

[Sukadev Bhattiprolu]

Thanks for your response. Yes I was referring to filesystems/Locking.
| 
| No, callers of ->writepage() should assure that
| 
|  - page is locked, and
| 
|  - writeback bit is clear on that page.
| 
| Which means that no IO is going on against this page. When
| Documentation/filesystems/Locking talks about "currently-in-progress
| I/O" it means any IO going to or fro the device, and "blocking against
| in-progress I/O" means blocking due to device queue congestion.

So is that referring to I/Os to/from the device from say pages other than
the one in ->writepage().

I was guessing that the test_set_buffer_locked() in __block_write_full_page()
is testing if I/O is in progress for a buffer belonging to this page. Is
that not the case ?

Re: Pagewriteback clarification

[Badari Pulavarty]

On Wed, 2005-09-28 at 13:17 +0400, Nikita Danilov wrote:
> Sukadev Bhattiprolu writes:
>  > Hi,
>  > 
>  > I have a couple of questions regarding PageWriteback flag and its
>  > relationship to locked buffers and in-progress I/O in progress.
>  > I would appreciate any input/pointers on this.
>  > 
>  > 1.  Based on documentation in Documentation/filesystems/filesystems
> 
> Cannot find such file. Are you talking about
> Documentation/filesystems/Locking?
> 
>  >     (LK 2.6.13), .writepage() can be called even if I/O is in progress
>  >     for the page.  And if an I/O is in progress, PageWriteback is TRUE
> 
> No, callers of ->writepage() should assure that
> 
>  - page is locked, and
> 
>  - writeback bit is clear on that page.
> 
> Which means that no IO is going on against this page. When
> Documentation/filesystems/Locking talks about "currently-in-progress
> I/O" it means any IO going to or fro the device, and "blocking against
> in-progress I/O" means blocking due to device queue congestion.

Hmm. Then what is this check doing in mpage_writepages() ?

                        if (wbc->sync_mode != WB_SYNC_NONE)
                                wait_on_page_writeback(page);

Is this to co-ordinate between  mpage_writepage() & mpage_writepages() ?
I don't see many users of wait_on_page_writeback(). What prevents
another write(2) modifying the pagecache data while a writepage()
or driver flushing the page to disk (since we dropped the lock on
the page) ?

Thanks,
Badari

Re: Pagewriteback clarification

[Nikita Danilov]

Badari Pulavarty writes:
 > On Wed, 2005-09-28 at 13:17 +0400, Nikita Danilov wrote:

[...]

 > > 
 > > No, callers of ->writepage() should assure that
 > > 
 > >  - page is locked, and
 > > 
 > >  - writeback bit is clear on that page.
 > > 
 > > Which means that no IO is going on against this page. When
 > > Documentation/filesystems/Locking talks about "currently-in-progress
 > > I/O" it means any IO going to or fro the device, and "blocking against
 > > in-progress I/O" means blocking due to device queue congestion.
 > 
 > Hmm. Then what is this check doing in mpage_writepages() ?
 > 
 >                         if (wbc->sync_mode != WB_SYNC_NONE)
 >                                 wait_on_page_writeback(page);

mpage_writepages() calls ->writepages() and, I as indicated above, it
has to assure that PG_writeback bit is
clear. wait_on_page_writeback(page) waits until this bit is cleared.

 > 
 > Is this to co-ordinate between  mpage_writepage() & mpage_writepages() ?
 > I don't see many users of wait_on_page_writeback(). What prevents
 > another write(2) modifying the pagecache data while a writepage()
 > or driver flushing the page to disk (since we dropped the lock on
 > the page) ?

Nothing, what's wrong with this? Page is re-dirtied and will be
later re-written to disk for another time.

 > 
 > Thanks,
 > Badari

Nikita.