geoff@edm.uucp (Geoff Coleman) (04/16/91)
In article <6597@awdprime.UUCP> dcm@codesmith.austin.ibm.com (Craig Miller) writes: > > > > Jerry, I think you're remembering "the good ole days".... :-) > > The number of inodes is, I believe, always ~3% of the size of > the filesystem. You can only get more inodes by extending. > > > Craig >-- >Craig Miller Internet: dcm@aixwiz.austin.ibm.com >IBM Austin Vnet: tkg007 at ausvmq >AIXV3 Change Team (level3) IBM internal: dcm@littleguy.austin.ibm.com >"I do not represent IBM or any other respectable company." But what we want is the good old days where we could say : mkfs device blocks inodes and get the number of inodes we want. We are running a disk with one database file on it. Because it is a 288 Mbyte there were ~72,000 inodes created by mkfs. We don't want this many inodes and we don't want to lose the space due to this allocation of inodes. As well it would be really nice to have a 512 byte or 1k file system for database work. Geoff Coleman Unexsys Systems
jpe@egr.duke.edu (John P. Eisenmenger) (04/19/91)
I noticed something yesterday that I'm not happy about in the least. When I ran "du" (while setting up "spacegripe") I noticed that all of the file block sizes were multiples of 4. In other words, it looks like IBM decided to not have any fragmented blocks. Being that my machine will be the target for many, many small files (spice input files, etc.), this is a very unat- tractive "feature" although I can see how it would speed up the filesystem. At least you know you won't run out of inodes... -John
richard@locus.com (Richard M. Mathews) (04/23/91)
jpe@egr.duke.edu (John P. Eisenmenger) writes: >I noticed something yesterday that I'm not happy about in the least. When >I ran "du" (while setting up "spacegripe") I noticed that all of the file >block sizes were multiples of 4. In other words, it looks like IBM decided >to not have any fragmented blocks. Being that my machine will be the target >for many, many small files (spice input files, etc.), this is a very unat- >tractive "feature" although I can see how it would speed up the filesystem. You don't mention what platform you are on (please, everyone, platform and release information is very helpful). I don't know what AIX on the 6000s does. AIX/370 and AIX PS/2 lack a real fragmentation scheme, but they do have a way of storing files of less than 384 bytes in the space normally used for inodes. The "du" and "ls" commands will show these as using up 0 blocks. Unfortunately, the 384 byte limit is small enough that not much more than small directories (and most importantly, hidden directories) can take advantage of this. The problem in AIX/370 and AIX PS/2 has been with combining fragmentation with the shadow block mechanism used to atomically commit or abort file system changes. Richard M. Mathews D efend richard@locus.com E stonian-Latvian-Lithuanian lcc!richard@seas.ucla.edu I ndependence ...!{uunet|ucla-se|turnkey}!lcc!richard
sja@sirius.hut.fi (Sakari Jalovaara) (04/24/91)
> In other words, it looks like IBM decided to not have any fragmented > blocks. Seems that way. We actually bought one System/6000 thinking we'd make it a dedicated news (NNTP) server. Haahhhaaaahaaaaaa heeehhheeeeee... ++sja