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@xxxxxxxxxxxxxxx > >> 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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
