xfs
[Top] [All Lists]

Re: TAKE 964002 - Don't wait for pending I/Os when purging blocks beyond

To: Bhagi rathi <jahnu77@xxxxxxxxx>
Subject: Re: TAKE 964002 - Don't wait for pending I/Os when purging blocks beyond eof.
From: Lachlan McIlroy <lachlan@xxxxxxx>
Date: Wed, 12 Dec 2007 15:04:19 +1100
Cc: sgi.bugs.xfs@xxxxxxxxxxxx, xfs@xxxxxxxxxxx
In-reply-to: <cc7060690712110852v185362a4q21a8de1c7e7334e@mail.gmail.com>
References: <20071210055955.0F96358C4C34@chook.melbourne.sgi.com> <cc7060690712110852v185362a4q21a8de1c7e7334e@mail.gmail.com>
Reply-to: lachlan@xxxxxxx
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird 2.0.0.9 (X11/20071031)
Bhagi rathi wrote:
On Dec 10, 2007 11:29 AM, Lachlan McIlroy <lachlan@xxxxxxx> wrote:

Don't wait for pending I/Os when purging blocks beyond eof.

On last close of a file we purge blocks beyond eof.  The same
code is used when we truncate the file size down.  In this case
we need to wait for any pending I/Os for dirty pages beyond the
new eof.  For the last close case we are not changing the file
size and therefore do not need to wait for any I/Os to complete.
This fixes a performance bottleneck where writes into the page
cache and cache flushes can become mutually exclusive.


Lachlan,

How the following is addressed if we don't wait for I/O to complete during
close of the file and
issue truncate:

        - We didn't waited for the I/O to complete
        - Truncated blocks beyond EOF.
        - These blocks are re-used for another transaction as meta-data.
        - Meta-data flush was induced. However the flush of meta-data
reached first before the data I/O
          because of some issues with under-lying driver. Later the file I/O
over-written the meta-data I/O.
          We have corruption of data.
This case will not happen.  For a truncate down we may have dirty pages
beyond eof that are in the process of being written to disk while we are
trying to shrink the file - we need to wait for those.  In the case of
truncating blocks beyond eof on last close we are not changing the file
size and so there cannot be pages beyond eof.  Any I/O that may be in
progress will be within the file size and not to any of the blocks we
are trying to free.


It seems the corruption could be in various ways. Isn't this the reason why truncate has to wait for the I/O to complete?
Corruption could certainly occur if we don't wait for I/O.  I think the
reason this code was added was to synchronize with direct I/O unwritten
extent conversions which could occur after the direct writer thread has
released the iolock and so we can't use the iolock alone as an I/O barrier.

I believe fundamental problem is once the blocks
are free'ed, the re-association should
not expect some I/O in concurrent to those same block addresses.

-Cheers,
 Bhagi.



Date: Mon Dec 10 16:59:09 AEDT 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-vniowait Inspected by: pleckie Author: lachlan

The following file(s) were checked into:
 longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb


Modid: xfs-linux-melb:xfs-kern:30220a fs/xfs/xfs_inode.c - 1.489 - changed
http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/>> xfs_inode.c.diff?r1=text&tr1=1.489&r2=text&tr2=1.488&f=h
http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/> xfs_inode.c.diff?r1=text&tr1=1.489&r2=text&tr2=1.488&f=h
http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.489&r2=text&tr2=1.488&f=h
       - Don't wait for pending I/Os when purging blocks beyond eof.







[[HTML alternate version deleted]]





<Prev in Thread] Current Thread [Next in Thread>