* 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: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
* 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
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.