[lkml]   [2000]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: nfsv3d wrong truncates over 4G
On Wed, Oct 25, 2000 at 06:26:25PM +0300, Matti Aarnio wrote:
> On Wed, Oct 25, 2000 at 03:57:39PM +0200, Andrea Arcangeli wrote:
> > This bug causes nfsd kernel based server to wrongly truncate files
> > while using offsets over 4G. With patch applied it starts to work right.
> Is it correct to limit it in anyway at the server ?
> Let the CLIENT to handle the O_LARGEFILE testing, and let the SERVER
> to just assume it being the situation ?

I don't follow. The patch avoids to lose the high 32bit of information
during the setattr call. I'm not limiting anything, I'm just allowing
the server to see the whole information that cames from the client.

> When the NFS server does file open, does it do it with O_LARGEFILE,
> or not ? Is there a standardized way to pass that flag over NFSv3 ?

NFS server needs to open with O_LARGEFILE to go over 2G. Currently
it does that unconditionally (nfsv2 can't ask over 4G by design anyways,
and in lfs in 2.2.18pre17aa1 we put an hard limit of 2G for nfsv2 clients
to avoid triggering bugs with any other non-linux server, if you need
more than 2G just use nfsv3).

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:41    [W:2.085 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site