This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Sat Apr 20 03:04:24 2024 Received: from lml.valinux.com (postfix@lml.valinux.com [198.186.203.19]) by herbie.ucs.indiana.edu (8.9.3/8.9.3) with ESMTP id EAA07126 for ; Fri, 17 Mar 2000 04:34:35 -0500 (EST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by lml.valinux.com (Postfix) with ESMTP id DB6D4590C4; Fri, 17 Mar 2000 01:34:14 -0800 (PST) Received: by vger.rutgers.edu via listexpand id ; Fri, 17 Mar 2000 03:24:35 -0500 Received: by vger.rutgers.edu id ; Fri, 17 Mar 2000 02:28:57 -0500 Received: from [216.240.32.1] ([216.240.32.1]:2938 "EHLO idiom.com") by vger.rutgers.edu with ESMTP id ; Fri, 17 Mar 2000 02:10:54 -0500 Received: from idiom.com (reiser.dial.idiom.com [216.240.37.24]) by idiom.com (8.9.3/8.9.3) with ESMTP id XAA78644; Thu, 16 Mar 2000 23:11:08 -0800 (PST) Message-Id: <38D1419C.AFAB8460@idiom.com> Date: Thu, 16 Mar 2000 23:18:36 +0300 From: Hans Reiser Reply-To: hans@reiser.to Organization: Namesys X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686) X-Accept-Language: en, ru Mime-Version: 1.0 To: Olaf Kirch Cc: hans@reiser.to, Alexander Viro , Andi Kleen , "Neil F. Brown" , linux-kernel@vger.rutgers.edu, linux-fsdevel@vger.rutgers.edu, reiserfs@devlinux.com Subject: Re: (reiserfs) reiserfs and knfsd and NFSv4 and volatile file handles References: <38CFF191.DAC18150@idiom.com> <20000316123100.D6339@monad.swb.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu X-Orcpt: rfc822;linux-kernel-outgoing-dig Olaf Kirch wrote: > > I've taken the NFSv4 WG off the Cc, because I think this is moving quite > a bit away from their interests. > > Here's a bunch of observations that may help (please take with > a grain of salt; it's been a while since I did active NFS coding): > > 1. There are various standards out there that very much like > "inode numbers" to be unique. Tools like tar will barf badly > if they're not. Whether they're supposed to be stable is a > different issue. Whether they are supposed to be just > 32 bit is also an entirely different issue. Reiserfs keys are guaranteed to be unique, else everything would collapse in our algorithms, so we are ok here. > > 2. When talking about NFS, "inode numbers" appear in two > different roles. First as the "fileid" attribute to > a file system object; this value is 32bit in v2 and > 64bit in v3. 64 bits are enough for now, but not for later. > Second, "inode numbers" are currently > used heavily in the file handles created by knfsd.  > > 3. Neil Brown is working on patches that allow variant > file handle layouts per filesystem. This will allow > reiserfs to use up the 32 bytes (64 in v3) as it > pleases. Cool. > > There are some boundary conditions like checking of export > points, and a certain portion of code (like connecting > dnodes) may have to be copied; but those are probably just > details that shouldn't affect the design of reiserfs. > > 4. The file handles used by the old user space nfsd have > never been invariant under moving to a different directory. > However I don't think anybody ever noticed except people doing > conformance testing or benchmarking. > > So there is some precedent if the reiserfs designers choose to > take an approach that ensures that the object id remains constant > as long as an object does not move to a different directory, > but nothing more. We need to change the key not after rename but after repack. > > 5. It may be worthwhile to put the entire key (including offset) > into an NFS file handle because ninety-odd percent of > all file handles are extremely short-lived (whereas the > packer is supposed to run once a day if I got Hans right). You got me right. > So the worst case would be that _some_ file handles arrive > that have the right directory and object ID but the wrong > offset. This error can probably be detected, I would assume. > This could be corrected by performing a directory search and > taking the performance hit; optionally, there could be a > small to medium sized cache that contains fix-up information > for these semi-stale file handles. Are you sure of this point? > > 6. It may not hurt much if reiserfs is aiming just at NFSv3 > and ignores NFSv2 completely. Exporting a modern file > system over 1980s technology is quite a bad match. Maybe we can do v3 in 2.4 and v4 in 2.6 when there will be a repacker. > > Just my 2 cents > Olaf > -- > Olaf Kirch | --- o --- Nous sommes du soleil we love when we play > okir@caldera.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax > +-------------------- Why Not?! ----------------------- > UNIX, n.: Spanish manufacturer of fire extinguishers. -- You can get ReiserFS at http://devlinux.org/namesys, and customizations and industrial grade support at reiser@idiom.com. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/