Re: [PATCH 1/4] vfs: vfs-level fiemap interface

[Jamie Lokier <jamie@shareable.org>]

Theodore Tso wrote:
> >    FIEMAP_EXTENT_READ_ENCODED
> >    FIEMAP_EXTENT_WRITE_ENCODED
> 
> If some application which wishes to use FIEMAP really wants to know
> whether it's safe to write to an extent while the fs is unmounted, we
> can add that flag later --- but I'm not that sure we really want to go
> there.

I agree.  If it were ever added, it would have the opposite sense to
FIEMAP_EXTENT_ENCODED: set would mean "can write".  Sounds messy and
suggests the sense of FIEMAP_EXTENT_ENCODED should be reversed so that
_set_ means safe to read - effectively "not safe unless filesystem
explicitly says it is".  But it's functionally adequate, not a real
bike shed colour clash :-)

> Do you have a use in mind for this interface where this would be
> useful?

Barely imaginable uses: boot loader, BIOS-stage device tester or
similar logging to a preallocated file, or a userspace benchmark
testing direct block device access to a preallocated file.

It's not something I'm interested in, just that it's barely
conceivable, and I only thought of it when Chris mentioned shared data
blocks.

So no.  I just wanted to clarify, because on most filesystems you
_can_ write to the data blocks safely, and that's an assumption that
Joe Obscure Boot Loader Hacker (who isn't familiar with modern
filesystems) might be tempted by.

One more thing, then:

How can you safely use !(flags & FLAG_EXTENT_ENCODED) anyway in
userspace code which is filesystem-independent?  What tells you that
the data isn't moved after calling FIEMAP and before unmounting, by
unrelated activity on the filesystem?

So should filesystems also set FLAG_EXTENT_ENCODED if there is any
chance the data will move without any explicit operation on that file,
even though the data itself is stored unencoded in data blocks?

-- Jamie