public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH V2] xfs_io: fix fiemap loop continuation
Date: Tue, 14 Feb 2012 12:00:12 +1100	[thread overview]
Message-ID: <20120214010012.GK7479@dastard> (raw)
In-Reply-To: <20120214004818.GA6766@infradead.org>

On Mon, Feb 13, 2012 at 07:48:18PM -0500, Christoph Hellwig wrote:
> On Tue, Feb 14, 2012 at 11:45:32AM +1100, Dave Chinner wrote:
> > On Mon, Feb 13, 2012 at 02:09:03PM -0500, Christoph Hellwig wrote:
> > > This actually seems to break 252 and 255 for me.
> > 
> > Ok, there was some code that expected last_logical to be in FSB
> > units, not bytes that I failed to convert.
> > 
> > Fixed version below.
> 
> Can you sent a relative patch to the previous one? I've already
> commited it a while ago.

Below.

-- 
Dave Chinner
david@fromorbit.com


xfs_io: fix fiemap loop continuation

From: Dave Chinner <dchinner@redhat.com>

When the fiemap command needs to retrieve more extents from the
kernel via a subsequent IO, it calculates the next logical block to
retrieve in file system block units. the fiemap needs the start
offset in bytes, not filesystem blocks.  Hence if the fiemap command
can loop forever retrieving the same blocks if the logical offset
offset of the next block in filesystem block units is smaller than
the number of bytes in a filessytem block. i.e. it will just loop
retreiving the first 32 extents from offset block zero.

Signed-off-by: Dave Chinner <dchinner@redhat.com>

---
Version 3
o update to current tree.

Version 2
o Fix remaining cases where last_logical was expected to be in FSB
  units rather than bytes.

 io/fiemap.c |   27 +++++++++++++++------------
 1 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/io/fiemap.c b/io/fiemap.c
index 99296dd..e32a416 100644
--- a/io/fiemap.c
+++ b/io/fiemap.c
@@ -75,12 +75,14 @@ print_verbose(
 	__u64			*last_logical)
 {
 	__u64			lstart;
+	__u64			llast;
 	__u64			len;
 	__u64			block;
 	char			lbuf[48];
 	char			bbuf[48];
 	char			flgbuf[16];
 
+	llast = *last_logical / blocksize;
 	lstart = extent->fe_logical / blocksize;
 	len = extent->fe_length / blocksize;
 	block = extent->fe_physical / blocksize;
@@ -88,11 +90,11 @@ print_verbose(
 	memset(lbuf, 0, sizeof(lbuf));
 	memset(bbuf, 0, sizeof(bbuf));
 
-	if (lstart != *last_logical) {
-		snprintf(lbuf, sizeof(lbuf), "[%llu..%llu]:", *last_logical,
+	if (lstart != llast) {
+		snprintf(lbuf, sizeof(lbuf), "[%llu..%llu]:", llast,
 			 lstart - 1ULL);
 		printf("%4d: %-*s %-*s %*llu\n", *cur_extent, foff_w, lbuf,
-		       boff_w, _("hole"), tot_w, lstart - *last_logical);
+		       boff_w, _("hole"), tot_w, lstart - llast);
 		(*cur_extent)++;
 		memset(lbuf, 0, sizeof(lbuf));
 	}
@@ -121,19 +123,20 @@ print_plain(
 	__u64			*last_logical)
 {
 	__u64			lstart;
+	__u64			llast;
 	__u64			block;
 	__u64			len;
 
+	llast = *last_logical / blocksize;
 	lstart = extent->fe_logical / blocksize;
 	len = extent->fe_length / blocksize;
 	block = extent->fe_physical / blocksize;
 
-	if (lstart != *last_logical) {
+	if (lstart != llast) {
 		printf("\t%d: [%llu..%llu]: hole", *cur_extent,
-		       *last_logical, lstart - 1ULL);
+		       llast, lstart - 1ULL);
 		if (lflag)
-			printf(_(" %llu blocks\n"),
-			       lstart - *last_logical);
+			printf(_(" %llu blocks\n"), lstart - llast);
 		else
 			printf("\n");
 		(*cur_extent)++;
@@ -281,6 +284,7 @@ fiemap_f(
 				print_plain(extent, lflag, blocksize,
 					    max_extents, &cur_extent,
 					    &last_logical);
+
 			if (extent->fe_flags & FIEMAP_EXTENT_LAST) {
 				last = 1;
 				break;
@@ -303,22 +307,21 @@ fiemap_f(
 		return 0;
 	}
 
-	if (cur_extent && last_logical < (st.st_size / blocksize)) {
+	if (cur_extent && last_logical < st.st_size) {
 		char	lbuf[32];
 
 		snprintf(lbuf, sizeof(lbuf), "[%llu..%llu]:",
-			 last_logical, (st.st_size / blocksize) - 1);
+			 last_logical / blocksize, (st.st_size / blocksize) - 1);
 		if (vflag) {
 			printf("%4d: %-*s %-*s %*llu\n", cur_extent,
 			       foff_w, lbuf, boff_w, _("hole"), tot_w,
-			       (st.st_size / blocksize) - last_logical);
+			       (st.st_size - last_logical) / blocksize);
 		} else {
 			printf("\t%d: %s %s", cur_extent, lbuf,
 			       _("hole"));
 			if (lflag)
 				printf(_(" %llu blocks\n"),
-				       (st.st_size / blocksize) -
-				       last_logical);
+				       (st.st_size - last_logical) / blocksize);
 			else
 				printf("\n");
 		}

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

      reply	other threads:[~2012-02-14  1:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-02  6:21 [PATCH] xfs_io: fix fiemap loop continuation Dave Chinner
2012-02-02  9:13 ` Christoph Hellwig
2012-02-13 19:09 ` Christoph Hellwig
2012-02-14  0:45   ` [PATCH V2] " Dave Chinner
2012-02-14  0:48     ` Christoph Hellwig
2012-02-14  1:00       ` Dave Chinner [this message]

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=20120214010012.GK7479@dastard \
    --to=david@fromorbit.com \
    --cc=hch@infradead.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox