All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Liu <jeff.liu@oracle.com>
To: Mark Tinguely <tinguely@sgi.com>
Cc: Christoph Hellwig <hch@infradead.org>, Ben Myers <bpm@sgi.com>,
	Chris Mason <chris.mason@oracle.com>,
	xfs@oss.sgi.com
Subject: Re: Introduce SEEK_DATA/SEEK_HOLE to XFS V5
Date: Thu, 12 Jan 2012 21:29:33 +0800	[thread overview]
Message-ID: <4F0EE03D.8090402@oracle.com> (raw)
In-Reply-To: <4F0DFA11.7030305@sgi.com>

Hi Mark,

Thanks for your comments!

On 01/12/2012 05:07 AM, Mark Tinguely wrote:

> 
> xfs_bmapi_read() returns the br_state == XFS_EXT_NORM for a hole.

Yes, this is key point I have missed before.

> There are a couple places that a hole can trigger a data test.
> BTW, I could not generate a large enough hole that xfs_bmapi_read()
> would return as more than one hole entry, so I will ignore those
> situations and just list the couple places that a hole may be match
> a data rule:
> 
> in xfs_seek_data():
> +        /*
> +         * Landed in an unwritten extent, try to find out the data
> +         * buffer offset from page cache firstly. If nothing was
> +         * found, treat it as a hole, and skip to check the next
> +         * extent, something just like above.
> +         */
> +        if (map[0].br_state == XFS_EXT_UNWRITTEN) {
> +            if (xfs_has_unwritten_buffer(inode, &map[0],
> +                             PAGECACHE_TAG_DIRTY,
> +                             &offset) ||
> +                xfs_has_unwritten_buffer(inode, &map[0],
> +                             PAGECACHE_TAG_WRITEBACK,
> +                             &offset)) {
> +                offset = max_t(loff_t, seekoff, offset);
> +                break;
> +            }
> +
> +            /* No data extent at the given offset */
> +            if (nmap == 1) {
> +                error = ENXIO;
> +                break;
> +            }
> +
> +            if (map[1].br_state == XFS_EXT_NORM ||
>             ^^^ could be a hole and not data^^^
> 
> I think you need to add back the br_startblock test:
> 
> +            if ((map[1].br_state == XFS_EXT_NORM &&
> +                 map[1].br_startblock != HOLESTARTBLOCK) ||

Ok, I'll add !isnullstartblock() test for normal extents test.

> 
> 
> in xfs_seek_hole():
> +        /*
> +         * Landed in a delay allocated extent or a real data extent,
> +         * if the next extent is landed in a hole or in an unwritten
> +         * extent but without data committed in the page cache, return
> +         * its offset. If the next extent has dirty data in page cache,
> +         * but its offset starts past both the start block of the map
> +         * and the seek offset, it still be a hole.
> +         */
> +        if (map[0].br_startblock == DELAYSTARTBLOCK ||
> +            map[0].br_state == XFS_EXT_NORM) {
>             ^^^ could be a hole ^^^
> 
>    and this only matters because this test is checked before the next test:
>        
> +
> +        /* Landed in a hole, its fine to return */
> +        if (map[0].br_startblock == HOLESTARTBLOCK) {
> +            offset = max_t(loff_t, seekoff,
> +                       XFS_FSB_TO_B(mp, map[0].br_startoff));
> +            break;
> +        }
> 
> 
> 
> Switching the order of these two tests would return the immediate offset
> starting a hole seek at the offset of a hole.

looks this issue is caused by missing hole test for extents at
XFS_EXT_NORM state. I'll fix them later.

Thanks,
-Jeff

> 
> 
> None of these conditions will result in data corruption, only earlier
> detection of a hole.


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2012-01-12 13:29 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-06 13:28 Introduce SEEK_DATA/SEEK_HOLE to XFS V5 Jeff Liu
2012-01-10 17:18 ` Ben Myers
2012-01-11  5:45   ` Jeff Liu
2012-01-11 21:06     ` Mark Tinguely
2012-01-12 16:22       ` Christoph Hellwig
2012-01-12 17:50         ` Ben Myers
2012-01-11 21:07     ` Mark Tinguely
2012-01-12 13:29       ` Jeff Liu [this message]
2012-01-12 16:39       ` Christoph Hellwig
2012-01-13  2:14         ` Jeff Liu
2012-01-11 21:12     ` Mark Tinguely
2012-01-12 13:52       ` Jeff Liu
2012-01-12 15:01         ` Mark Tinguely
2012-01-12 16:41           ` Christoph Hellwig
2012-01-12 17:39             ` Ben Myers
2012-01-13  2:41           ` Jeff Liu
2012-01-11 15:43 ` Ben Myers
2012-01-11 22:28   ` Ben Myers
2012-01-12 13:21     ` Jeff Liu
2012-01-12 12:53   ` Jeff Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F0EE03D.8090402@oracle.com \
    --to=jeff.liu@oracle.com \
    --cc=bpm@sgi.com \
    --cc=chris.mason@oracle.com \
    --cc=hch@infradead.org \
    --cc=tinguely@sgi.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.