From owner-freebsd-arch Mon Mar 11 0:23:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 11BEA37B405 for ; Mon, 11 Mar 2002 00:23:42 -0800 (PST) Received: from pool0243.cvx21-bradley.dialup.earthlink.net ([209.179.192.243] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16kL5e-0006V3-00; Mon, 11 Mar 2002 00:23:30 -0800 Message-ID: <3C8C6965.69DBA92A@mindspring.com> Date: Mon, 11 Mar 2002 00:23:01 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Garance A Drosihn , arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t References: <96479.1015833733@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > In message , Garance A Drosihn writes: > >So if I want to compare > > /afs/rpi.edu/campus/lang/ruby/1.6/README > >to > > ~drosehn/private/myruby/README > >then the stat call has to have the same st_dev for both of > >those files. > > I'm missing something here, unless README is a device, st_dev > has no meaning, no ? It has meaning as part of a tuple that uniquely identifies the file. It's arguable whether or not the identification is permitted to be transient, or must be persistant. For example, AppleTalk requires that the 32 bit file identifier on a volume be non-transient, so that the identifier can be cached in the resource fork of another file, and used to look it up at an indeterminite future date. This was a significant issue in the NetWare for UNIX 4.x NXFS filesystem design I worked on at Novell in 1993/1994. The implication of this is that, for certain file sharing protocols, an identifier that was computed or otherwise derived from an expanded value (e.g. a 64 bit value) must be persistant, and not transiently derived (e.g. persistant only over the lifetime of a system uptime). For NFSv3 and NFSv2, for example, the recovery of file handles following a server failure requires that the value of the handles be persistant over a server reboot. A kernel AppleTalk server would have similar requirements, as would a kernel NetWare server. For user space, you could use an external database, but you would then end up with the common synchronization issues faced by hosted OS's, where the host OS doesn't go through the same enforcement code as the OS it is hosting. Of course, you don't have to take my word for it... ] Date: Sun, 10 Mar 2002 17:07:55 -0500 (EST) ] From: Garrett Wollman ] Message-Id: <200203102207.g2AM7tN11702@khavrinen.lcs.mit.edu> ] To: arch@FreeBSD.org ] Subject: Re: Increasing the size of dev_t and ino_t [ ... ] ] In other words, `long long' is a perfectly acceptable underlying type ] for both dev_t and ino_t. The only other advice POSIX gives on the ] subject is: ] ] # The st_ino and st_dev fields taken together uniquely identify the ] # file within the system. ] ] -GAWollman -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message