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