On 2020/1/15 下午10:05, David Howells wrote:

Qu Wenruo [off-list ref] wrote:

quoted

At least for btrfs, only unaligned extents get padding zeros.

What is "unaligned" defined as?  The revised cachefiles reads and writes 256k
blocks, except for the last - which gets rounded up to the nearest page (which
I'm assuming will be some multiple of the direct-I/O granularity).  The actual
size of the data is noted in an xattr so I don't need to rely on the size of
the cachefile.

"Unaligned" means "unaligned to fs sector size". In btrfs it's page
size, thus it shouldn't be a problem for your 256K block size.

quoted

(c): A multi-device fs (btrfs) can have their own logical address mapping.
Meaning the bytenr returned makes no sense to end user, unless used for
that fs specific address space.

For the purpose of cachefiles, I don't care where it is, only whether or not
it exists.  Further, if a DIO read will return a short read when it hits a
hole, then I only really care about detecting whether the first byte exists in
the block.

It might be cheaper, I suppose, to initiate the read and have it fail
immediately if no data at all is present in the block than to do a separate
ask of the filesystem.

quoted

You won't like this case either.
(d): Compressed extents
One compressed extent can represents more data than its on-disk size.

Same answer as above.  Btw, since I'm using DIO reads and writes, would these
get compressed?

Yes. DIO will also be compressed unless you set the inode to nocompression.

And you may not like this btrfs internal design:
Compressed extent can only be as large as 128K (uncompressed size).

So 256K block write will be split into 2 extents anyway.
And since compressed extent will cause non-continuous physical offset,
it will always be two extents to fiemap, even you're always writing in
256K block size.

Not sure if this matters though.

quoted

And even more bad news:
(e): write time dedupe
Although no fs known has implemented it yet (btrfs used to try to
support that, and I guess XFS could do it in theory too), you won't
known when a fs could get such "awesome" feature.

I'm not sure this isn't the same answer as above either, except if this
results in parts of the file being "filled in" with blocks of zeros that I
haven't supplied.

The example would be, you have written 256K data, all filled with 0xaa.
And it committed to disk.
Then the next time you write another 256K data, all filled with 0xaa.
Then instead of writing this data onto disk, the fs chooses to reuse
your previous written data, doing a reflink to it.

So fiemap would report your latter 256K has the same bytenr of your
previous 256K write (since it's reflinked), and with SHARED flag.

 Couldn't this be disabled on an inode-by-inode basis, say
with an ioctl?

No fs has implemented yet, but for btrfs, it has a switch to disable it
in a per-inode base.

Thanks,
Qu

quoted

quoted

Without being able to trust the filesystem to tell me accurately what I've
written into it, I have to use some other mechanism.  Currently, I've
switched to storing a map in an xattr with 1 bit per 256k block, but that
gets hard to use if the file grows particularly large and also has
integrity consequences - though those are hopefully limited as I'm now
using DIO to store data into the cache.

Would you like to explain why you want to know such fs internal info?

As Andreas pointed out, fscache+cachefiles is used to cache data locally for
network filesystems (9p, afs, ceph, cifs, nfs).  Cached files may be sparse,
with unreferenced blocks not currently stored in the cache.

I'm attempting to move to a model where I don't use bmap and don't monitor
bit-waitqueues to find out when page flags flip on backing files so that I can
copy data out, but rather use DIO directly to/from the network filesystem
inode pages.

Since the backing filesystem has to keep track of whether data is stored in a
file, it would seem a shame to have to maintain a parallel copy on the same
medium, with the coherency issues that entail.

David