Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: Why Partition a Hard Disk
Message-ID: <66800@sun.uucp>
Date: 2 Sep 88 19:52:54 GMT
References: <4360004@wdl1.UUCP> <1988Aug31.174144.1694@utzoo.uucp>
Sender: news@sun.uucp
Lines: 23

> The one significant resource limitation that remains in some systems is
> 16-bit inode numbers, limiting the number of files that can exist in a
> single filesystem.  4BSD has fixed this, but at least the early System V
> releases didn't (I'm not sure about the current ones).

Only the ones that have 1) picked up the 4.2BSD file system and 2) have changed
inumbers throughout the system to be 32 bits :-).

S5 still uses the V7 file system, which still has 16 bit inumbers in directory
entries.  Even if some vendor adds the 4.2BSD file system to their System V
kernel, there's still a potential problem if they don't, for example, change
the "st_ino" field in the "stat" structure from an "unsigned short" to an
"unsigned long"; if you have inumbers > 65535 on that file system, "st_ino" is
no longer unique on that file system - this probably won't break *most*
programs, but I have no idea which ones it *will* break, or how badly they'll
break.

Furthermore, note that adding NFS to S5 - even if you *haven't* added the
4.2BSD file system - causes the exact same problem, if for example you mount a
4.2BSD file system with inumbers > 65535 from some *other* machine.

Yes, changing the "stat" structure may be painful.  Not changing it may be
painful as well....