On Wed, Aug 07, 2019 at 10:12:12PM +1000, Dave Chinner wrote: > On Wed, Aug 07, 2019 at 06:17:42PM +0800, Murphy Zhou wrote: > > ccing linux-xfs@xxxxxxxxxxxxxxx > > > > Hi, > > > > Tracked down this to be a xfs specific issue: > > > > If we call copy_file_range with a large offset like this: > > > > loff_t off = 9223372036854710270; // 2 ** 63 > > ret = copy_file_range(fd_in, 0, fd_out, &off, 65537, 0); > > That's not 2**63: Ya! I was looking too roughly. > > $ echo $((9223372036854710270 + 65537)) > 9223372036854775807 > > $ echo $((2**63 - 1)) > 9223372036854775807 > > i.e. it's LLONG_MAX, not an overflow. XFS sets sb->s_maxbytes in > xfs_max_file_offset to: > > (1 << BITS_PER_LONG - 1) - 1 = 2**63 - 1 = LLONG_MAX. > > So no matter how we look at it, this operation should not return > EFBIG on XFS. > > > (test programme cfrbig.c attached) > > > > xfs has it done successfully, while ext4 returns EFBIG. > > ext4 has a max file size of 2**32 * blocksize, so it doesn't support > files larger than 16TB. So it will give EFBIG on this test. > > /me compiles and runs the test program on his workstation: > > $ ls -l foobar > -rw------- 1 dave dave 10737418240 Apr 12 14:46 foobar > $ ./a.out foobar bar > ret 65537 > $ ls -l bar > -rw-r--r-- 1 dave dave 9223372036854775807 Aug 7 22:11 bar > $ > > That looks like a successful copy to me, not EINVAL or EFBIG... Thanks Dave for the confirmation! This testcase needs some fix. Murphy > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx
