Date: Mon, 11 Mar 2002 10:55:01 +0100 (CET) From: Harti Brandt <brandt@fokus.gmd.de> 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: <20020311105221.O516-100000@beagle.fokus.gmd.de> In-Reply-To: <17497.1015840078@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 Mar 2002, Poul-Henning Kamp wrote: PK>In message <20020311102511.M516-100000@beagle.fokus.gmd.de>, Harti Brandt write PK>s: PK> PK>>There is an explicit requirement in POSIX: it requires a given PK>>st_ino/st_dev pair to uniqely identify a file. I take this to mean: if two PK>>files have the same st_ino/st_dev pair, they are the same file. If I mount PK>>the same volume in different places in the tree any file on that volume PK>>must have the same st_ino/st_dev pair in both mount points. As worded by PK>>POSIX the st_ino/st_dev pairs are not required to be persistant through PK>>reboots. It can, however, be hard to implement persistant file handles for PK>>NFS based on non-persistant st_info/st_dev pairs. PK> PK>(Sorry, I confused st_dev and st_rdev earlier). PK> PK>Ok, I think we are on the same page now. PK> PK>I don't think any of the stuff headed for -current would give you PK>trouble in this respect. Just because we _can_ assign a random PK>st_dev doesn't mean we will shoot ourselves in the foot by doing so :-) PK> PK>And still, I see no pressure to increase the size of (u)dev_t on PK>any platforms. Given that (u)dev_t is 32 bit according to types(5) you are right. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fhg.de 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?20020311105221.O516-100000>