Re: FIBMAP/FIEMAP discrepancy for CAP_SYS_RAWIO

[Andreas Dilger <adilger@sun.com>]

On Sep 08, 2009  09:47 +0100, Jamie Lokier wrote:
> 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?

Partly true - if the caller only passes in space for a single extent
to be returned then the traversal would stop as soon as a discontinuity
is found.  For ext2/ext3 this would happen at 12 blocks into the
filesystem, because the first indirect block is allocated after the
12th data block, so the amount of scanning would be very small.

> 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.

By all means, I don't object to FIBMAP being fixed to allow non-root
access, but until that happens (and then users start using those
kernels) it won't work for non-root users.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.