silent truncation for large file offsets
Subsystems (2)
Quoted 9 lines · Christoph Hellwig
Quoted 1 line
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
Quoted 5 lines
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.
--b.
Quoted 13 lines · J. Bruce Fields
Quoted 12 lines · Christoph Hellwig
Quoted 1 line
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/testso the file gets created with the correct size on the server, but the clients shows the size truncated.
Quoted 9 lines
Quoted 2 lines
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?
Quoted 26 lines · Trond Myklebust
Quoted 13 lines · J. Bruce Fields
Quoted 12 lines · Christoph Hellwig
Quoted 1 line
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/testso the file gets created with the correct size on the server, but the clients shows the size truncated.
Quoted 9 lines
Quoted 2 lines
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:
Quoted 8 lines
static inline
loff_tnfs_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?
I guess so
(That's confusing, though--in general, shouldn't the maximum file size be one *more* than the maximum offset? But looks like st_size is off_t, so, I guess this is just how it is.)
--b.
Quoted 34 lines · J. Bruce Fields
Quoted 33 lines · Trond Myklebust
Quoted 13 lines · J. Bruce Fields
Quoted 12 lines · Christoph Hellwig
Quoted 1 line
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/testso the file gets created with the correct size on the server, but the clients shows the size truncated.
Quoted 9 lines
Quoted 2 lines
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_tnfs_size_to_loff_t(__u64 size){ if (size > (__u64) OFFSET_MAX - 1) return OFFSET_MAX - 1; return (loff_t) size; }
Quoted 7 lines
Quoted 1 line
Should be "return
OFFSET_MAX", no?I guess so
(That's confusing, though--in general, shouldn't the maximum file size be one *more* than the maximum offset? But looks like
st_sizeisoff_t, so, I guess this is just how it is.)
If you ever manage to write to offset OFFSET_MAX, you will never know...
Quoted 10 lines · Trond Myklebust
I'll bet it's this:
static inline
loff_tnfs_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?
Yes. That (or rather a slighty nicer version using min_t) fixes the test case for me.