Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!gryphon!turnkey!jackv From: jackv@turnkey.gryphon.COM (Jack F. Vogel) Newsgroups: comp.unix.i386 Subject: Re: Still Waiting for Inode fixes, ZZZZZZZZ Keywords: inode, UNIX, news Message-ID: <6398@turnkey.gryphon.COM> Date: 7 Dec 89 16:28:56 GMT References: <434@telxon.UUCP> <613@buster.irby.com> <257cf96c:240.6comp.unix.i386;1@nstar.UUCP> Reply-To: jackv@turnkey.gryphon.COM Organization: Turnkey Computer Consultants, Westchester, CA Lines: 27 In article <257cf96c:240.6comp.unix.i386;1@nstar.UUCP> akcs.larry@nstar.UUCP (Larry Snyder) writes: >Let's be nice now - I've based my information on what I heard >when I called ISC technical support - and I was told that under System V >the inode allocation could not be changed. Under SCO, using the manual I >changed the number of inodes using mkfs. I was just relaying information >that I received from the folks who did the port. Good Grief!!! Here you are spending all your time and effort bashing ISC and now we are supposed to believe you are a reliable vehicle to relay what their technical support team has to say! Give us a break. I think personally that what is going on here is probably a misunderstanding on what was being said. I don't believe that ISC support would assert that there is no way to control how many inodes a filesystem has using an explicit number in the mkfs command. What they may have meant is that once you have a filesystem made with x inodes there is no way to change that number (you could diddle with the superblock using fsdb, but I don't think the filesystem integrity would be maintained) short of recreating it using mkfs again. In fact, I wondered if the original poster actually was experiencing the inode bug that a previous poster alluded to, or if he just actually ran out of inodes and thought that this was a bug. Disclaimer: My opinions only! -- Jack F. Vogel jackv@seas.ucla.edu AIX Technical Support - or - Locus Computing Corp. jackv@ifs.umich.edu