All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Tinguely <tinguely@sgi.com>
To: jeff.liu@oracle.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: Wed, 11 Jan 2012 15:07:29 -0600	[thread overview]
Message-ID: <4F0DFA11.7030305@sgi.com> (raw)
In-Reply-To: <4F0D21E5.7010908@oracle.com>


xfs_bmapi_read() returns the br_state == XFS_EXT_NORM for a hole.
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) ||


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.


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

  parent reply	other threads:[~2012-01-11 21:07 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 [this message]
2012-01-12 13:29       ` Jeff Liu
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=4F0DFA11.7030305@sgi.com \
    --to=tinguely@sgi.com \
    --cc=bpm@sgi.com \
    --cc=chris.mason@oracle.com \
    --cc=hch@infradead.org \
    --cc=jeff.liu@oracle.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.