filefrag and reflink

filefrag and reflink

[Chris Murphy]

xfsprogs 4.17.0 mkfs with reflink=1
kernel 4.17.6

$ fallocate -l 1g tmp2
$ cp --reflink tmp2 tmp3
$ filefrag -v *
Filesystem type is: 58465342
File size of tmp2 is 1073741824 (262144 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..  130136:         24..    130160: 130137:             unwritten
   1:   130137..  260280:     131082..    261225: 130144:     130161: unwritten
   2:   260281..  262143:     264714..    266576:   1863:     261226:
last,unwritten,eof
tmp2: 3 extents found
File size of tmp3 is 1073741824 (262144 blocks of 4096 bytes)
tmp3: 0 extents found
[chris@f28s xfs]$


Is this expected? When I do it on Btrfs, I see identical information
for the two files after reflink copy, with flags "unwritten,shared".

Regular files behave as expected, I'm only seeing this on reflink
copies of fallocated files.




-- 
Chris Murphy

Re: filefrag and reflink

[Darrick J. Wong]

On Wed, Jul 18, 2018 at 12:41:27PM -0600, Chris Murphy wrote:
> xfsprogs 4.17.0 mkfs with reflink=1
> kernel 4.17.6
> 
> $ fallocate -l 1g tmp2
> $ cp --reflink tmp2 tmp3
> $ filefrag -v *
> Filesystem type is: 58465342
> File size of tmp2 is 1073741824 (262144 blocks of 4096 bytes)
>  ext:     logical_offset:        physical_offset: length:   expected: flags:
>    0:        0..  130136:         24..    130160: 130137:             unwritten
>    1:   130137..  260280:     131082..    261225: 130144:     130161: unwritten
>    2:   260281..  262143:     264714..    266576:   1863:     261226:
> last,unwritten,eof
> tmp2: 3 extents found
> File size of tmp3 is 1073741824 (262144 blocks of 4096 bytes)
> tmp3: 0 extents found
> [chris@f28s xfs]$
> 
> 
> Is this expected? When I do it on Btrfs, I see identical information
> for the two files after reflink copy, with flags "unwritten,shared".

Yes.  xfs doesn't share unwritten extents; what would be the point?

--D

> Regular files behave as expected, I'm only seeing this on reflink
> copies of fallocated files.
> 
> 
> 
> 
> -- 
> Chris Murphy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: filefrag and reflink

[Eric Sandeen]

On 7/18/18 12:59 PM, Darrick J. Wong wrote:
> On Wed, Jul 18, 2018 at 12:41:27PM -0600, Chris Murphy wrote:
>> xfsprogs 4.17.0 mkfs with reflink=1
>> kernel 4.17.6
>>
>> $ fallocate -l 1g tmp2
>> $ cp --reflink tmp2 tmp3
>> $ filefrag -v *
>> Filesystem type is: 58465342
>> File size of tmp2 is 1073741824 (262144 blocks of 4096 bytes)
>>  ext:     logical_offset:        physical_offset: length:   expected: flags:
>>    0:        0..  130136:         24..    130160: 130137:             unwritten
>>    1:   130137..  260280:     131082..    261225: 130144:     130161: unwritten
>>    2:   260281..  262143:     264714..    266576:   1863:     261226:
>> last,unwritten,eof
>> tmp2: 3 extents found
>> File size of tmp3 is 1073741824 (262144 blocks of 4096 bytes)
>> tmp3: 0 extents found
>> [chris@f28s xfs]$
>>
>>
>> Is this expected? When I do it on Btrfs, I see identical information
>> for the two files after reflink copy, with flags "unwritten,shared".
> 
> Yes.  xfs doesn't share unwritten extents; what would be the point?
> 
> --D

<materializes somewhere on a US western interstate>

Seems a little weird that bare cp will create a written file full of
zeros, while a cp --reflink will create a sparse file, though?

-Eric

Re: filefrag and reflink

[Darrick J. Wong]

On Wed, Jul 18, 2018 at 01:27:40PM -0700, Eric Sandeen wrote:
> 
> 
> On 7/18/18 12:59 PM, Darrick J. Wong wrote:
> > On Wed, Jul 18, 2018 at 12:41:27PM -0600, Chris Murphy wrote:
> >> xfsprogs 4.17.0 mkfs with reflink=1
> >> kernel 4.17.6
> >>
> >> $ fallocate -l 1g tmp2
> >> $ cp --reflink tmp2 tmp3
> >> $ filefrag -v *
> >> Filesystem type is: 58465342
> >> File size of tmp2 is 1073741824 (262144 blocks of 4096 bytes)
> >>  ext:     logical_offset:        physical_offset: length:   expected: flags:
> >>    0:        0..  130136:         24..    130160: 130137:             unwritten
> >>    1:   130137..  260280:     131082..    261225: 130144:     130161: unwritten
> >>    2:   260281..  262143:     264714..    266576:   1863:     261226:
> >> last,unwritten,eof
> >> tmp2: 3 extents found
> >> File size of tmp3 is 1073741824 (262144 blocks of 4096 bytes)
> >> tmp3: 0 extents found
> >> [chris@f28s xfs]$
> >>
> >>
> >> Is this expected? When I do it on Btrfs, I see identical information
> >> for the two files after reflink copy, with flags "unwritten,shared".
> > 
> > Yes.  xfs doesn't share unwritten extents; what would be the point?
> > 
> > --D
> 
> <materializes somewhere on a US western interstate>
> 
> Seems a little weird that bare cp will create a written file full of
> zeros, while a cp --reflink will create a sparse file, though?

Well see therein lies the problem.  The documentation for cp states:

"When --reflink[=always] is specified, perform a lightweight copy, where
the data blocks are copied only when modified."

The lightest weight copy for a bunch of zeroes is a hole.  That's the
interpretation I went with. :)

OTOH the "copied only when modified" language does sort of imply that
you'd share the unwritten extents and then COW them, but that involves
adding more machinery to _iomap_begin to copy-write over zeroes,
which seems pointless and would involve a format change since old
kernels wouldn't know to check for shared unwritten extents...

...and if your worry is about being able to write to tmp3 without
hitting ENOSPC then you'll have to fallocate + funshare the file
separately anyway.

--D

> 
> -Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: filefrag and reflink

[Eric Sandeen]

On 7/18/18 1:47 PM, Darrick J. Wong wrote:
> On Wed, Jul 18, 2018 at 01:27:40PM -0700, Eric Sandeen wrote:
>>
>>
>> On 7/18/18 12:59 PM, Darrick J. Wong wrote:
>>> On Wed, Jul 18, 2018 at 12:41:27PM -0600, Chris Murphy wrote:
>>>> xfsprogs 4.17.0 mkfs with reflink=1
>>>> kernel 4.17.6
>>>>
>>>> $ fallocate -l 1g tmp2
>>>> $ cp --reflink tmp2 tmp3
>>>> $ filefrag -v *
>>>> Filesystem type is: 58465342
>>>> File size of tmp2 is 1073741824 (262144 blocks of 4096 bytes)
>>>>  ext:     logical_offset:        physical_offset: length:   expected: flags:
>>>>    0:        0..  130136:         24..    130160: 130137:             unwritten
>>>>    1:   130137..  260280:     131082..    261225: 130144:     130161: unwritten
>>>>    2:   260281..  262143:     264714..    266576:   1863:     261226:
>>>> last,unwritten,eof
>>>> tmp2: 3 extents found
>>>> File size of tmp3 is 1073741824 (262144 blocks of 4096 bytes)
>>>> tmp3: 0 extents found
>>>> [chris@f28s xfs]$
>>>>
>>>>
>>>> Is this expected? When I do it on Btrfs, I see identical information
>>>> for the two files after reflink copy, with flags "unwritten,shared".
>>>
>>> Yes.  xfs doesn't share unwritten extents; what would be the point?
>>>
>>> --D
>>
>> <materializes somewhere on a US western interstate>
>>
>> Seems a little weird that bare cp will create a written file full of
>> zeros, while a cp --reflink will create a sparse file, though?
> 
> Well see therein lies the problem.  The documentation for cp states:
> 
> "When --reflink[=always] is specified, perform a lightweight copy, where
> the data blocks are copied only when modified."
> 
> The lightest weight copy for a bunch of zeroes is a hole.  That's the
> interpretation I went with. :)

OK, but surely the reflink syscall semantics have authority over this
behavior, not one user of the syscall, right?

Except, uh, did it ever get documented?

> OTOH the "copied only when modified" language does sort of imply that
> you'd share the unwritten extents and then COW them, but that involves
> adding more machinery to _iomap_begin to copy-write over zeroes,
> which seems pointless and would involve a format change since old
> kernels wouldn't know to check for shared unwritten extents...

Oh :(
 
> ...and if your worry is about being able to write to tmp3 without
> hitting ENOSPC then you'll have to fallocate + funshare the file
> separately anyway.

Unless you had some really weird app where you planned to write to
mutually exclusive ranges of a reflinked fallocated file ... ;)

TBH while the btrfs behavior does seem a little pointless it's at
least very predictable and understandable.

But, well, if XFS doesn't check for shared unwritten I guess there's
nothing worth doing.  Just thought it might be worth hashing out before
it gets defaulted anyway...

-Eric

> --D
> 
>>
>> -Eric
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: filefrag and reflink

[Darrick J. Wong]

On Wed, Jul 18, 2018 at 02:07:46PM -0700, Eric Sandeen wrote:
> 
> 
> On 7/18/18 1:47 PM, Darrick J. Wong wrote:
> > On Wed, Jul 18, 2018 at 01:27:40PM -0700, Eric Sandeen wrote:
> >>
> >>
> >> On 7/18/18 12:59 PM, Darrick J. Wong wrote:
> >>> On Wed, Jul 18, 2018 at 12:41:27PM -0600, Chris Murphy wrote:
> >>>> xfsprogs 4.17.0 mkfs with reflink=1
> >>>> kernel 4.17.6
> >>>>
> >>>> $ fallocate -l 1g tmp2
> >>>> $ cp --reflink tmp2 tmp3
> >>>> $ filefrag -v *
> >>>> Filesystem type is: 58465342
> >>>> File size of tmp2 is 1073741824 (262144 blocks of 4096 bytes)
> >>>>  ext:     logical_offset:        physical_offset: length:   expected: flags:
> >>>>    0:        0..  130136:         24..    130160: 130137:             unwritten
> >>>>    1:   130137..  260280:     131082..    261225: 130144:     130161: unwritten
> >>>>    2:   260281..  262143:     264714..    266576:   1863:     261226:
> >>>> last,unwritten,eof
> >>>> tmp2: 3 extents found
> >>>> File size of tmp3 is 1073741824 (262144 blocks of 4096 bytes)
> >>>> tmp3: 0 extents found
> >>>> [chris@f28s xfs]$
> >>>>
> >>>>
> >>>> Is this expected? When I do it on Btrfs, I see identical information
> >>>> for the two files after reflink copy, with flags "unwritten,shared".
> >>>
> >>> Yes.  xfs doesn't share unwritten extents; what would be the point?
> >>>
> >>> --D
> >>
> >> <materializes somewhere on a US western interstate>
> >>
> >> Seems a little weird that bare cp will create a written file full of
> >> zeros, while a cp --reflink will create a sparse file, though?
> > 
> > Well see therein lies the problem.  The documentation for cp states:
> > 
> > "When --reflink[=always] is specified, perform a lightweight copy, where
> > the data blocks are copied only when modified."
> > 
> > The lightest weight copy for a bunch of zeroes is a hole.  That's the
> > interpretation I went with. :)
> 
> OK, but surely the reflink syscall semantics have authority over this
> behavior, not one user of the syscall, right?
> 
> Except, uh, did it ever get documented?

What, the ioctl?

http://man7.org/linux/man-pages/man2/ioctl_ficlonerange.2.html

Not that having that helps; guess who wrote that documentation? :)

> > OTOH the "copied only when modified" language does sort of imply that
> > you'd share the unwritten extents and then COW them, but that involves
> > adding more machinery to _iomap_begin to copy-write over zeroes,
> > which seems pointless and would involve a format change since old
> > kernels wouldn't know to check for shared unwritten extents...
> 
> Oh :(
>  
> > ...and if your worry is about being able to write to tmp3 without
> > hitting ENOSPC then you'll have to fallocate + funshare the file
> > separately anyway.
> 
> Unless you had some really weird app where you planned to write to
> mutually exclusive ranges of a reflinked fallocated file ... ;)
> 
> TBH while the btrfs behavior does seem a little pointless it's at
> least very predictable and understandable.
> 
> But, well, if XFS doesn't check for shared unwritten I guess there's
> nothing worth doing.  Just thought it might be worth hashing out before
> it gets defaulted anyway...

<nod> I usually try to go for the simplest solution, design-wise...

--D

> -Eric
> 
> > --D
> > 
> >>
> >> -Eric
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: filefrag and reflink

[Carlos Maiolino]

> > zeros, while a cp --reflink will create a sparse file, though?
> 
> Well see therein lies the problem.  The documentation for cp states:
> 
> "When --reflink[=always] is specified, perform a lightweight copy, where
> the data blocks are copied only when modified."
> 
> The lightest weight copy for a bunch of zeroes is a hole.  That's the
> interpretation I went with. :)
> 
> OTOH the "copied only when modified" language does sort of imply that
> you'd share the unwritten extents and then COW them, but that involves
> adding more machinery to _iomap_begin to copy-write over zeroes,
> which seems pointless and would involve a format change since old
> kernels wouldn't know to check for shared unwritten extents...
> 
> ...and if your worry is about being able to write to tmp3 without
> hitting ENOSPC then you'll have to fallocate + funshare the file
> separately anyway.

/me should read the whole thread before replying to earlier messages :P

> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Carlos

Re: filefrag and reflink

[Carlos Maiolino]

On Wed, Jul 18, 2018 at 01:27:40PM -0700, Eric Sandeen wrote:
> 
> 
> On 7/18/18 12:59 PM, Darrick J. Wong wrote:
> > On Wed, Jul 18, 2018 at 12:41:27PM -0600, Chris Murphy wrote:
> >> xfsprogs 4.17.0 mkfs with reflink=1
> >> kernel 4.17.6
> >>
> >> $ fallocate -l 1g tmp2
> >> $ cp --reflink tmp2 tmp3
> >> $ filefrag -v *
> >> Filesystem type is: 58465342
> >> File size of tmp2 is 1073741824 (262144 blocks of 4096 bytes)
> >>  ext:     logical_offset:        physical_offset: length:   expected: flags:
> >>    0:        0..  130136:         24..    130160: 130137:             unwritten
> >>    1:   130137..  260280:     131082..    261225: 130144:     130161: unwritten
> >>    2:   260281..  262143:     264714..    266576:   1863:     261226:
> >> last,unwritten,eof
> >> tmp2: 3 extents found
> >> File size of tmp3 is 1073741824 (262144 blocks of 4096 bytes)
> >> tmp3: 0 extents found
> >> [chris@f28s xfs]$
> >>
> >>
> >> Is this expected? When I do it on Btrfs, I see identical information
> >> for the two files after reflink copy, with flags "unwritten,shared".
> > 
> > Yes.  xfs doesn't share unwritten extents; what would be the point?
> > 
> > --D
> 
> <materializes somewhere on a US western interstate>
> 
> Seems a little weird that bare cp will create a written file full of
> zeros, while a cp --reflink will create a sparse file, though?

cp actually can have different behaviors when --reflink is specified, from the
manpage (formatting slightly modified):

"
By default, sparse SOURCE files are detected by a crude heuristic and the
corresponding DEST file is made sparse  as  well. That  is  the  behavior
selected  by  --sparse=auto.
Specify --sparse=always  to  create  a  sparse DEST file whenever the SOURCE
file contains a long enough sequence of zero bytes.  Use --sparse=never to
inhibit creation of sparse files.

When --reflink[=always] is specified, perform a lightweight copy,  where  the
data  blocks  are copied  only  when  modified.   If  this is not possible the
copy fails, or if --reflink=auto is specified, fall back to a standard copy.
"

> 
> -Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Carlos

Re: filefrag and reflink

[Darrick J. Wong]

On Thu, Jul 19, 2018 at 01:34:50PM +0200, Carlos Maiolino wrote:
> On Wed, Jul 18, 2018 at 01:27:40PM -0700, Eric Sandeen wrote:
> > 
> > 
> > On 7/18/18 12:59 PM, Darrick J. Wong wrote:
> > > On Wed, Jul 18, 2018 at 12:41:27PM -0600, Chris Murphy wrote:
> > >> xfsprogs 4.17.0 mkfs with reflink=1
> > >> kernel 4.17.6
> > >>
> > >> $ fallocate -l 1g tmp2
> > >> $ cp --reflink tmp2 tmp3
> > >> $ filefrag -v *
> > >> Filesystem type is: 58465342
> > >> File size of tmp2 is 1073741824 (262144 blocks of 4096 bytes)
> > >>  ext:     logical_offset:        physical_offset: length:   expected: flags:
> > >>    0:        0..  130136:         24..    130160: 130137:             unwritten
> > >>    1:   130137..  260280:     131082..    261225: 130144:     130161: unwritten
> > >>    2:   260281..  262143:     264714..    266576:   1863:     261226:
> > >> last,unwritten,eof
> > >> tmp2: 3 extents found
> > >> File size of tmp3 is 1073741824 (262144 blocks of 4096 bytes)
> > >> tmp3: 0 extents found
> > >> [chris@f28s xfs]$
> > >>
> > >>
> > >> Is this expected? When I do it on Btrfs, I see identical information
> > >> for the two files after reflink copy, with flags "unwritten,shared".
> > > 
> > > Yes.  xfs doesn't share unwritten extents; what would be the point?
> > > 
> > > --D
> > 
> > <materializes somewhere on a US western interstate>
> > 
> > Seems a little weird that bare cp will create a written file full of
> > zeros, while a cp --reflink will create a sparse file, though?
> 
> cp actually can have different behaviors when --reflink is specified, from the
> manpage (formatting slightly modified):
> 
> "
> By default, sparse SOURCE files are detected by a crude heuristic and the
> corresponding DEST file is made sparse  as  well. That  is  the  behavior
> selected  by  --sparse=auto.
> Specify --sparse=always  to  create  a  sparse DEST file whenever the SOURCE
> file contains a long enough sequence of zero bytes.  Use --sparse=never to
> inhibit creation of sparse files.

But it can't have different behaviors, because there's an (undocumented)
requirement that sparse=auto if reflink=always, which implies that if cp
succeeds at delegating the file copy to the kernel it won't do anything
else.  From coreutils 8.28 (Ubuntu 18.04):

  if (x.reflink_mode == REFLINK_ALWAYS && x.sparse_mode != SPARSE_AUTO)
    {
      error (0, 0, _("--reflink can be used only with --sparse=auto"));
      usage (EXIT_FAILURE);
    }


> When --reflink[=always] is specified, perform a lightweight copy,  where  the
> data  blocks  are copied  only  when  modified.   If  this is not possible the
> copy fails, or if --reflink=auto is specified, fall back to a standard copy.

Yep.  Here's the code that invokes FICLONE (the function clone_file is a
wrapper of the ioctl):

  /* --attributes-only overrides --reflink.  */
  if (data_copy_required && x->reflink_mode)
    {
      bool clone_ok = clone_file (dest_desc, source_desc) == 0;
      if (clone_ok || x->reflink_mode == REFLINK_ALWAYS)
        {
          if (!clone_ok)
            {
              error (0, errno, _("failed to clone %s from %s"),
                     quoteaf_n (0, dst_name), quoteaf_n (1, src_name));
              return_val = false;
              goto close_src_and_dst_desc;
            }
          data_copy_required = false;
        }
    }

>From my reading of that, if the kernel succeeds at the FICLONE, then cp
decides that the data copy is finished and moves on.  That heavily
implies that it's ok for the kernel to do what it wants as far as
unwritten vs. hole...

--D

> "
> 
> > 
> > -Eric
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -- 
> Carlos
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html