All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Andreas Dilger <adilger@sun.com>
Cc: Florian Weimer <fw@deneb.enyo.de>, linux-fsdevel@vger.kernel.org
Subject: Re: FIBMAP/FIEMAP discrepancy for CAP_SYS_RAWIO
Date: Tue, 8 Sep 2009 09:47:20 +0100	[thread overview]
Message-ID: <20090908084720.GB31909@shareable.org> (raw)
In-Reply-To: <20090908072349.GC4197@webber.adilger.int>

Andreas Dilger wrote:
> On Sep 07, 2009  16:26 +0000, Florian Weimer wrote:
> > * Andreas Dilger:
> > > If you are implementing a tool to use this, I would code it to try
> > > FIEMAP first, then FIBMAP (if it is running as root, or it gets
> > > fixed in some future kernel), then just do without (as it most likely
> > > does already today).
> > 
> > If FIBMAP is unsafe, it's likely exposed by concurrent changes to the
> > file, so using it would still be unsafe for backup purposes.  And I
> > really only need the number of the first block.  (I want to optimize
> > reading of Maildir-style folders, mainly for backup purposes.)
> 
> Given that the worst that can happen for your particular application
> if FIBMAP gets the wrong block number is a sub-optimal ordering for
> the file copy, there is no risk in doing this.
> 
> For the FIEMAP code, since you only need the first block number, just
> pass it a single fiemap_extent so that it doesn't spend time generating
> a full list of extents that you don't need to use.

With FIEMAP, filesystems which don't use extents will still scan a
potentially large region of the disk doing block lookups won't they,
just to maximise the size of the first extent in a large file?

Assuming yes, FIBMAP would be faster than FIEMAP in those cases, which
may be a reason to give it the same permissions, so it can be used.

-- Jamie

  reply	other threads:[~2009-09-08  8:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-06 13:39 FIBMAP/FIEMAP discrepancy for CAP_SYS_RAWIO Florian Weimer
2009-09-07 10:50 ` Andreas Dilger
2009-09-07 13:28   ` Theodore Tso
2009-09-07 16:26   ` Florian Weimer
2009-09-08  7:23     ` Andreas Dilger
2009-09-08  8:47       ` Jamie Lokier [this message]
2009-09-09 16:13         ` Andreas Dilger

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=20090908084720.GB31909@shareable.org \
    --to=jamie@shareable.org \
    --cc=adilger@sun.com \
    --cc=fw@deneb.enyo.de \
    --cc=linux-fsdevel@vger.kernel.org \
    /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.