Re: [PATCH 0/4] Fiemap, an extent mapping ioctl - round 2

[Dave Chinner <david@fromorbit.com>]

On Mon, Jul 07, 2008 at 05:53:54PM +0100, Jamie Lokier wrote:
> Dave Chinner wrote:
> > Like:
> > 
> > # xfs_freeze -f <mntpt>
> > # xfs_bmap -vvp <file>
> > # <do something nasty with direct block access>
> > # xfs_freeze -u <mntpt>
> 
> ^^^ Oh, exactly the sort of thing which led to this quote from Andreas
> Dilger on why FIEMAP is *not* suitable for this, on generic filesystems :-)
> 
>     "EEEEEK [...] Directly writing underneath a filesystem is major
>     bad news and will likely corrupt the filesystem because [page
>     cache reasons]."

Yes - that's why I said "Do something nasty". IIRC, grub does
exactly this to try to work around the fact that it mixes raw
disk access with mounted filesystems....

FWIW, I've used the output of xfs_bmap for direct block *read*
access in the past - it's very handy for tracking down corruption
problems as a result of hardware misdirecting writes.

> Besides, if you're using the currently-XFS-specific freeze capability,

<sigh>

Freeze is not XFS specific.

http://marc.info/?l=linux-fsdevel&m=121482849815436&w=2
http://marc.info/?l=linux-kernel&m=121511426713644&w=2

> a simple fsync() before the xfs_bmap, inside the freeze, will be
> sufficient won't it?

The freeze makes sync redundant. 

[ As an aside, not many people around here seem to grok what
'freezing the filesystem' really means. It means 'put the filesystem
in a 100% consistent state on disk and prevent further modification
until unfrozen'. It provides guarantees that sync doesn't as sync
only needs to guarantee the filesystem is in a *recoverable* state
on disk at a single point in time. ]

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com