Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!sdd.hp.com!spool2.mu.edu!uunet!mcsun!ukc!pyrltd!root44!praxis!itcp From: itcp@praxis.co.uk (Tom Parke) Newsgroups: comp.arch Subject: Re: Sun bogosities, including MMU thrashing Message-ID: <5655@newton.praxis.co.uk> Date: 29 Jan 91 15:09:29 GMT References: <5257@auspex.auspex.com> <3956@skye.ed.ac.uk> <5390@auspex.auspex.com> <1991Jan21.225211.17757@gpu.utcs.utoronto.ca> <1991Jan24.193458.1 Organization: Praxis, Bath, UK Lines: 24 suitti@ima.isc.com (Stephen Uitti) writes: >It would also be nice if the inode information were near something >else. For that matter it would be nice if inodes had a larger >name space than 16 bits (V7) and could be allocated dynamically, >rather than statically (at mkfs time). A good spot would be in >directories. This makes hard links more difficult. This should >not be a deterrent. It would also seem to make the inode look up less efficient - because inodes are in a single contiguous space the value of any given inode can be fetched in a single disk access. I once designed and implemented a file store where I did everything right (bit map for free blocks, nice simple algorithm to cluster block allocated to files, all management data held in the middle of the disk to reduce average seek) except I let the inode space be dynamic, adding the extra indirection killed any advantages I might otherwise have gained. Tom -- Tom Parke (my opinions and spelling are strictly temporary) itcp@praxis.co.uk Praxis, 20 Manvers St., Bath BA1 1PX, UK