Message-ID: <23358.1579097103@warthog.procyon.org.uk>
Date:   Wed, 15 Jan 2020 14:05:03 +0000
From:   David Howells <dhowells@...hat.com>
To:     Qu Wenruo <quwenruo.btrfs@....com>
Cc:     dhowells@...hat.com, linux-fsdevel@...r.kernel.org,
        viro@...iv.linux.org.uk, hch@....de, tytso@....edu,
        adilger.kernel@...ger.ca, darrick.wong@...cle.com, clm@...com,
        josef@...icpanda.com, dsterba@...e.com, linux-ext4@...r.kernel.org,
        linux-xfs@...r.kernel.org, linux-btrfs@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: Problems with determining data presence by examining extents?

Qu Wenruo <quwenruo.btrfs@....com> wrote:

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

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

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

> 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.  Couldn't this be disabled on an inode-by-inode basis, say
with an ioctl?

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

Powered by blists - more mailing lists