poc@sun.com (11/01/90)
> From: Phil Trubey <phil@shl.uucp> > Subject: inode limit in SCO/Unix. > > We are running news on an SCO Unix machine. The news spool partition > is a large area of about 800MB. Unfortunately, long before the disk > fills up, the filesystem runs out of inodes. > > A quick look at mkfs(ADM) informs me that the maximum # of inodes that > it can make is 65500. > > Is there a way around this limit, short of splitting up the disk into > 4 smaller partitions? The short answer is 'no'. Inodes in your system are apparently being indexed by a 16-bit integer. You can't change that without (at least) redefining the format of directory entries, recompiling most of the system and many utilities like LS, changing FSCK and MKFS and and and ... Of course, if you're _very_ lucky, it might be enough to just change a few constants and recompile _everything_ (for safety :-). While we're on the subject, some years ago we thought of a possiblly interesting mod to the kernel implementation of 'mount()' which could alleviate this sort of thing (no flames please, this hasn't been fully worked out :-) Since the dawn of time, mount has _replaced_ some inode with the root inode of the system being mounted. Instead, why not link the new inode on a list so they are _both_ available? Then we could mount several disks under '/usr', to give an example. In case of repeated directory entries in these various 'root's, just take the first one on the list. Comments anyone?
gwyn@smoke.brl.mil (Doug Gwyn) (11/01/90)
In article <24905@adm.BRL.MIL> emsca!intevep!emsca!usb!poc@sun.com writes: >Since the dawn of time, mount has _replaced_ some inode with the root inode >of the system being mounted. Instead, why not link the new inode on a list >so they are _both_ available? Then we could mount several disks under '/usr', Plan 9 has already implemented a similar scheme, with the added advantage that ordinary (nonprivileged) users may exploit it.