Questions about FIEMAP

Questions about FIEMAP

[Wang, Zhiye]

Hello everyone,

After googled a bit, I got information that btrfs supports FIEMAP (as "cp" needs it), but it's not valid for "write" operation.

I guess we cannot write to block device directly after get block list using FIEMAP. This is because:

1. COW feature of btrfs (but this can be disabled using NOCOW)
2. File system rebalance
3. Defragmentation

Aren't item #2 and #3 also a problem for "read" operation? For example, after "cp" get block list using FIEMAP, file system rebalance occurs, So, previous result of FIEMAP is not valid anymore.

Or maybe I misunderstood something. Please correct me.



Thanks
Mike

Re: Questions about FIEMAP

[Duncan]

Wang, Zhiye posted on Mon, 12 Oct 2015 04:37:55 +0000 as excerpted:

> I guess we cannot write to block device directly after get block list
> using FIEMAP. This is because:
> 
> 1. COW feature of btrfs (but this can be disabled using NOCOW)

I'm a user not a dev and many of the specifics of this discussion will 
with little doubt be above my head, but a warning on this assumption, 
just in case you overlooked it...

Btrfs' snapshot feature conflicts with nocow, because a snapshot locks in 
place existing extents, relying on cow for any rewrite, to write the new 
blocks elsewhere.

So what happens when a nocow file is snapshotted and then written into?

Simple enough, it's effectively cow1.  That is, the first write to a 
particular block of a nocow file after a snapshot will still cow it, but 
the file retains its nocow attribute, and further writes to the same 
block will rewrite the block in its now existing new location... until 
the next snapshot locks that too in place, of course.

Bottom line, in the presence of snapshotting, particularly scheduled 
snapshotting that the admin may have forgotten about and/or doesn't know 
the consequences of, you can't rely on nocow actually being absolute 
rewrite-in-place nocow.

So just in case you weren't aware, don't assume what can't be assumed. 
=:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: Questions about FIEMAP

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1196 bytes --]

On Mon, Oct 12, 2015 at 04:37:55AM +0000, Wang, Zhiye wrote:
> Hello everyone,
> 
> After googled a bit, I got information that btrfs supports FIEMAP (as "cp" needs it), but it's not valid for "write" operation.
> 
> I guess we cannot write to block device directly after get block list using FIEMAP. This is because:
> 
> 1. COW feature of btrfs (but this can be disabled using NOCOW)
> 2. File system rebalance
> 3. Defragmentation
> 
> Aren't item #2 and #3 also a problem for "read" operation? For example, after "cp" get block list using FIEMAP, file system rebalance occurs, So, previous result of FIEMAP is not valid anymore.

   That's correct. If you use FIEMAP to get the blocks of a file, and
then balance the FS or defrag the file, then even without an explicit
write to the file, the file's location will have changed. This is the
same reason that btrfs doesn't support swap files (although I don't
know if swapon uses FIEMAP directly, or if there's just some
equivalent mechanism to get the blocks).

   Hugo.

-- 
Hugo Mills             | Have found Lost City of Atlantis. High Priest is
hugo@... carfax.org.uk | winning at quoits
http://carfax.org.uk/  |
PGP: E2AB1DE4          |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Questions about FIEMAP

[David Sterba]

On Mon, Oct 12, 2015 at 04:37:55AM +0000, Wang, Zhiye wrote:
> After googled a bit, I got information that btrfs supports FIEMAP (as
> "cp" needs it), but it's not valid for "write" operation.

The FIEMAP output is informative, there's no guarantee that the extent
information does not change before it reaches the caller.

> I guess we cannot write to block device directly after get block list
> using FIEMAP.

Beware that there's another layer of translation that maps the logical
offsets to physical offsets, basically the RAID layer. So even if you
get 'physical offset' from FIEMAP, it's still the 'logical' offset from
the POV of the filesytem and has no correspondence to the block device
offset.

> This is because:
> 
> 1. COW feature of btrfs (but this can be disabled using NOCOW)
> 2. File system rebalance
> 3. Defragmentation

This always reflects the 'logical' offset from the filesystem POV.

Re: Questions about FIEMAP

[Eric Sandeen]

On 10/11/15 11:37 PM, Wang, Zhiye wrote:
> Hello everyone,
> 
> After googled a bit, I got information that btrfs supports FIEMAP (as "cp" needs it), but it's not valid for "write" operation.

cp should not be using fiemap any more.  It was for a while, until they realized that copying based on fiemap output could lead to corruption because things changed between the fiemap call and the actual copy...

> I guess we cannot write to block device directly after get block list using FIEMAP. This is because:
> 
> 1. COW feature of btrfs (but this can be disabled using NOCOW)
> 2. File system rebalance
> 3. Defragmentation
> 
> Aren't item #2 and #3 also a problem for "read" operation? For example, after "cp" get block list using FIEMAP, file system rebalance occurs, So, previous result of FIEMAP is not valid anymore.
> 
> Or maybe I misunderstood something. Please correct me.

That all may be true for btrfs, but more fundamentally as dsterba said, nothing guarantees that the layout won't change *immediately* after your fiemap call.  This is the case on any filesystem, not just btrfs.

-Eric

RE: Questions about FIEMAP

[Wang, Zhiye]

Thank you all for your comments.

A further question is: if I mount a btrfs file system in "readonly" mode, will any operation cause the blocks of a file get changed?


Regards
Mike



-----Original Message-----
From: Eric Sandeen [mailto:sandeen@redhat.com] 
Sent: Monday, October 12, 2015 9:27 PM
To: Wang, Zhiye; linux-btrfs@vger.kernel.org
Subject: Re: Questions about FIEMAP

On 10/11/15 11:37 PM, Wang, Zhiye wrote:
> Hello everyone,
> 
> After googled a bit, I got information that btrfs supports FIEMAP (as "cp" needs it), but it's not valid for "write" operation.

cp should not be using fiemap any more.  It was for a while, until they realized that copying based on fiemap output could lead to corruption because things changed between the fiemap call and the actual copy...

> I guess we cannot write to block device directly after get block list using FIEMAP. This is because:
> 
> 1. COW feature of btrfs (but this can be disabled using NOCOW) 2. File 
> system rebalance 3. Defragmentation
> 
> Aren't item #2 and #3 also a problem for "read" operation? For example, after "cp" get block list using FIEMAP, file system rebalance occurs, So, previous result of FIEMAP is not valid anymore.
> 
> Or maybe I misunderstood something. Please correct me.

That all may be true for btrfs, but more fundamentally as dsterba said, nothing guarantees that the layout won't change *immediately* after your fiemap call.  This is the case on any filesystem, not just btrfs.

-Eric

Re: Questions about FIEMAP

[Duncan]

Wang, Zhiye posted on Wed, 28 Oct 2015 09:57:29 +0000 as excerpted:

> Thank you all for your comments.
> 
> A further question is: if I mount a btrfs file system in "readonly"
> mode, will any operation cause the blocks of a file get changed?

Note that both bind-mounts and btrfs subvolume mounts can be used to make 
parts of a filesystem appear in multiple locations in the filesystem 
tree.  Because these different mounts can be separately mounted read-only 
or writable, there's no guarantee that just because a filesystem or part 
of it is read-only mounted in one location, it's read-only mounted 
everywhere it can be accessed, and thus no guarantee that files even on a 
read-only mounted filesystem or subvolume won't actually change out from 
under you.

However, bind-mounts in particular aren't btrfs specific, so just because 
btrfs subvolumes add another case in which the above can be true, doesn't 
mean bind-mounts can't be used on other filesystems to effect the same 
sort of otherwise read-only file instabilities.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman