Date: Mon, 11 Mar 2002 00:23:01 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Garance A Drosihn <drosih@rpi.edu>, arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <3C8C6965.69DBA92A@mindspring.com> References: <96479.1015833733@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote: > In message <p05101539b8b186d47384@[128.113.24.47]>, 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 <wollman@lcs.mit.edu> ] 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C8C6965.69DBA92A>