* silent truncation for large file offsets @ 2016-02-08 18:33 Christoph Hellwig 2016-02-08 19:30 ` J. Bruce Fields 0 siblings, 1 reply; 6+ messages in thread From: Christoph Hellwig @ 2016-02-08 18:33 UTC (permalink / raw) To: linux-nfs ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: silent truncation for large file offsets 2016-02-08 18:33 silent truncation for large file offsets Christoph Hellwig @ 2016-02-08 19:30 ` J. Bruce Fields 2016-02-08 19:45 ` Trond Myklebust 0 siblings, 1 reply; 6+ messages in thread From: J. Bruce Fields @ 2016-02-08 19:30 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-nfs 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. --b. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: silent truncation for large file offsets 2016-02-08 19:30 ` J. Bruce Fields @ 2016-02-08 19:45 ` Trond Myklebust 2016-02-08 19:54 ` J. Bruce Fields 2016-02-08 19:58 ` Christoph Hellwig 0 siblings, 2 replies; 6+ messages in thread From: Trond Myklebust @ 2016-02-08 19:45 UTC (permalink / raw) To: J. Bruce Fields; +Cc: Christoph Hellwig, Linux NFS Mailing List On Mon, Feb 8, 2016 at 2:30 PM, J. Bruce Fields <bfields@fieldses.org> 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? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: silent truncation for large file offsets 2016-02-08 19:45 ` Trond Myklebust @ 2016-02-08 19:54 ` J. Bruce Fields 2016-02-08 20:04 ` Trond Myklebust 2016-02-08 19:58 ` Christoph Hellwig 1 sibling, 1 reply; 6+ messages in thread From: J. Bruce Fields @ 2016-02-08 19:54 UTC (permalink / raw) To: Trond Myklebust; +Cc: Christoph Hellwig, Linux NFS Mailing List On Mon, Feb 08, 2016 at 02:45:54PM -0500, Trond Myklebust wrote: > On Mon, Feb 8, 2016 at 2:30 PM, J. Bruce Fields <bfields@fieldses.org> 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? 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: silent truncation for large file offsets 2016-02-08 19:54 ` J. Bruce Fields @ 2016-02-08 20:04 ` Trond Myklebust 0 siblings, 0 replies; 6+ messages in thread From: Trond Myklebust @ 2016-02-08 20:04 UTC (permalink / raw) To: J. Bruce Fields; +Cc: Christoph Hellwig, Linux NFS Mailing List On Mon, Feb 8, 2016 at 2:54 PM, J. Bruce Fields <bfields@fieldses.org> wrote: > On Mon, Feb 08, 2016 at 02:45:54PM -0500, Trond Myklebust wrote: >> On Mon, Feb 8, 2016 at 2:30 PM, J. Bruce Fields <bfields@fieldses.org> 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? > > 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.) If you ever manage to write to offset OFFSET_MAX, you will never know... ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: silent truncation for large file offsets 2016-02-08 19:45 ` Trond Myklebust 2016-02-08 19:54 ` J. Bruce Fields @ 2016-02-08 19:58 ` Christoph Hellwig 1 sibling, 0 replies; 6+ messages in thread From: Christoph Hellwig @ 2016-02-08 19:58 UTC (permalink / raw) To: Trond Myklebust Cc: J. Bruce Fields, Christoph Hellwig, Linux NFS Mailing List On Mon, Feb 08, 2016 at 02:45:54PM -0500, Trond Myklebust wrote: > 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? Yes. That (or rather a slighty nicer version using min_t) fixes the test case for me. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-02-08 20:04 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-02-08 18:33 silent truncation for large file offsets Christoph Hellwig 2016-02-08 19:30 ` J. Bruce Fields 2016-02-08 19:45 ` Trond Myklebust 2016-02-08 19:54 ` J. Bruce Fields 2016-02-08 20:04 ` Trond Myklebust 2016-02-08 19:58 ` Christoph Hellwig
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).