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@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
