On Mon, Feb 8, 2016 at 2:30 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote:
> On Mon, Feb 08, 2016 at 10:33:28AM -0800, Christoph Hellwig wrote:
>> >From a Linux client to a Linux server (in fact the same system in this
>> example), NFSv4.1, XFS file system:
>>
>> root@vm:~/xfstests# truncate --size 9223372036854775807 /mnt/nfs1/test
>> root@vm:~/xfstests# ls -l /mnt/nfs1/test
>> -rw-r--r-- 1 root root 9223372036854775806 Feb 8 18:30 /mnt/nfs1/test
>> root@vm:~/xfstests# ls -l /mnt/test/test
>> -rw-r--r-- 1 root root 9223372036854775807 Feb 8 18:30 /mnt/test/test
>>
>> so the file gets created with the correct size on the server, but
>> the clients shows the size truncated.
>>
>> This is extraced from xfstests generic/911 which tests clone
>> functionality and fails because of this issue.
>
> Took a quick look at wireshark, and GETATTR is returning the correct
> (larger) size.
>
> Also FSINFO (this is v3) returns 9223372036854775807 as the maximum file
> size.
>
I'll bet it's this:
static inline loff_t nfs_size_to_loff_t(__u64 size)
{
if (size > (__u64) OFFSET_MAX - 1)
return OFFSET_MAX - 1;
return (loff_t) size;
}
Should be "return OFFSET_MAX", no?
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
