From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 19 13:12:57 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 670661065672 for ; Wed, 19 Jan 2011 13:12:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 1F6E98FC19 for ; Wed, 19 Jan 2011 13:12:56 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEACxyNk2DaFvO/2dsb2JhbACED6EosF+PW4Ekgzh0BIRvhi+LOg X-IronPort-AV: E=Sophos;i="4.60,344,1291611600"; d="scan'208";a="105951528" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 19 Jan 2011 08:12:55 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E6FE9B411F; Wed, 19 Jan 2011 08:12:55 -0500 (EST) Date: Wed, 19 Jan 2011 08:12:55 -0500 (EST) From: Rick Macklem To: Daniel Braniss Message-ID: <800508241.469728.1295442775861.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers@freebsd.org Subject: Re: NFS: file too large X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 13:12:57 -0000 > > :Well, since a server specifies the maximum file size it can > > :handle, it seems good form to check for that in the client. > > :(Although I'd agree that a server shouldn't crash if a read/write > > : that goes beyond that limit.) > > : > > :Also, as Matt notes, off_t is signed. As such, it looks to me like > > :the check could mess up if uio_offset it right near > > 0x7fffffffffffffff, > > :so that uio->ui_offset + uio->uio_resid ends up negative. I think > > the > > :check a little above that for uio_offset < 0 should also check > > :uio_offset + uio_resid < 0 to avoid this. > > : > > :rick > > > > Yes, though doing an overflow check in C, at least with newer > > versions > > of GCC, requires a separate comparison. The language has been > > mangled > > pretty badly over the years. > > > > > > if (a + b < a) -> can be optimized-out by the compiler > > > > if (a + b < 0) -> also can be optimized-out by the compiler > > > > x = a + b; > > if (x < a) -> this is ok (best method) > > > > x = a + b; > > if (x < 0) -> this is ok > > Ok, thanks. I'll admit to being an old K+R type guy. > > my question, badly written, was why not let the underlaying fs (ufs, > zfs, etc) > have the last word, instead of the nfsclient having to guess? Is there > a problem in sending back the error? > Well, the principal I try and apply in the name of interoperability is: 1 - The client should adhere to the RFCs as strictly as possible 2 - The server should assume the loosest interpretation of the RFCs. For me #1 applies. ie. If a server specifies a maximum file size, the client should not violate that. (Meanwhile the server should assume that clients will exceed the maximum sooner or later.) Remember that the server might be a Netapp, EMC, ... and those vendors mostly test their servers against Linux, Solaris clients. (I've tried to convince them to fire up FreeBSD systems in-house for testing and even volunteered to help with the setup, but if they've done so, I've never heard about it. Their usual response is "come to connectathon". See below.) Here's an NFSv4.0 example: - RFC3530 describes the "dircount" argument for Readdir as a "hint of the maximum number of bytes of directory information" (in 4th para of pg 191). One vendor ships an NFSv4 client that always sets this value to 0. Their argument is that, since it is only a "hint" it can be anything they feel like putting there. (Several servers crapped out because of this in the early days.) Part of the problem is that I am not in a position to attend the interoperability testing events like www.connectathon.org, where these things are usually discovered (and since they are covered under an NDA that attendies sign, I don't find out the "easy way" when problems occur). rick