Loosely speaking, one way to tell the theoretical maximum you can store on a file system is to do a "df" command. If you add the -i parameter, that will tell you the number of inodes you have available. The maximum number of files will be equal to the smaller of the 1K blocks and the inodes. If you bump up the number of inodes, you will increase the amount of file system overhead, but also increase the number of files that can be stored. When the number of inodes >= the number of 1K blocks, inodes will no longer be the limiting factor, and the number of 1K blocks available will be the number of files you can store on that file system.
Note that _none_ of this has anything to do with the size of the underlying blocksize that the DASD was formatted with. That is another variable, independent of this bit of discussion, but relevant in that it determines the maximum number of 1K blocks you start with, before you start subtracting for inodes, etc. The same will be true for 4K blocksizes (just divide by 4 after doing the mke2fs). The fact that you ran out of inodes means that if you re-ran the mke2fs with a different inode value, you would be able to store more files on that file system. Proper selection of inode values frequently isn't an issue, but it can become one, as in this case. The fact that unused space showed up in your "df" commands means that the space was there to be used, but couldn't be used because an inode wasn't available to point to it. It does not mean that "ECKD overhead" made the space unavailable to start with. _That_ overhead gets "subtracted" before Linux gets to see the DASD. Formatting DASD with various blocksizes can be compared by doing a "cat /proc/dasd/devices" and using the "active at blocksize: 4096, 600840 blocks, 2347 MB" data between the different runs to compare. Mark Post -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Jim Sibley Sent: Monday, March 22, 2004 12:39 PM To: [EMAIL PROTECTED] Subject: Myth of the 1K blocksize on eckd (corrected) To answer both Mark and Tom 1) Both the 1k and 4k block experiment topped out at 54% of the file system full, so, yes, you do run out of inodes sooner, but you have more "capacity" for inodes with 4k blocks. Additionally, chasing the inode chain from disk (not cache) would be quicker with 4k blocks because there would be 1/4 the number of i/o's. 2) No, you do not get more blocks with 1k blocksize because of the heavy eckd overhead. 1k 4k blocks 1,626,740 2,366,164 And fewer blocks are used to contain directory information in the 4k case. If you increase the number of inodes, you will still get more small files on a 4k eckd image. Tom is right in that, if some of your files are more than 4k, then 4k rapidly becomes the choice, even if you are not inihibited by eckd formatting. Even if /etc, which are "small files", most of the files are greater than 1k and and a goodly number are over 4k. I don't see how 1k blocks are reasonable on 3390 ecked devices under any circumstances. ===== Jim Sibley RHCT, Implementor of Linux on zSeries "Computer are useless.They can only give answers." Pablo Picasso __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
