wolf@grasp1.univ-lyon1.fr (Christophe Wolfhugel) (04/11/91)
I have a jfs (created with SMIT) that has little inodes on it (less than 10k) and I'd like to have much more. Is there a way do do it dynamically, is jfs the bad choice (info exploer says that inodes can't be specifies on jfs). Any advice? Thanx. -- Christophe Wolfhugel (on irc: Zolf) | Email: wolf@grasp1.univ-lyon1.fr INSA Lyon - Departement Informatique | "Lapalisse au bordel: la duree de" 69621 Villeurbanne Cedex | "l'attente est fonction de la longueur" France | "de la queue."
jerry@heyman.austin.ibm.com (Jerry Heyman) (04/11/91)
In article <1991Apr11.064139.16221@grasp1.univ-lyon1.fr> wolf@grasp1.univ-lyon1.fr (Christophe Wolfhugel) writes: |>I have a jfs (created with SMIT) that has little inodes on it (less than 10k) |>and I'd like to have much more. Is there a way do do it dynamically, is jfs |>the bad choice (info exploer says that inodes can't be specifies on jfs). |> If I remember correctly, the number of inodes grows dynamically as need be. You start off with a small allocation and then the jfs allocates them as need be. |>Any advice? Thanx. |> |>-- |>Christophe Wolfhugel (on irc: Zolf) | Email: wolf@grasp1.univ-lyon1.fr jerry -- Jerry Heyman Internet : jerry@ajones.austin.ibm.com PSP Development Environment Tools VNET : HEYMAN at AUSTIN Austin, TX 78758 IBM T-R : jerry@heyman.austin.ibm.com *** All opinions expressed are exactly that - my opinions and NOT IBM's
dcm@codesmith.austin.ibm.com (Craig Miller) (04/12/91)
In article <6585@awdprime.UUCP> jerry@heyman.austin.ibm.com (Jerry Heyman) writes: >In article <1991Apr11.064139.16221@grasp1.univ-lyon1.fr> wolf@grasp1.univ-lyon1.fr (Christophe Wolfhugel) writes: >|>I have a jfs (created with SMIT) that has little inodes on it (less than 10k) >|>and I'd like to have much more. Is there a way do do it dynamically, is jfs >|>the bad choice (info exploer says that inodes can't be specifies on jfs). >|> > >If I remember correctly, the number of inodes grows dynamically as need be. >You start off with a small allocation and then the jfs allocates them as >need be. 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."
marc@watson.ibm.com (Marc Auslander) (04/12/91)
I believe that the AIXV3 jfs uses the BSD inode scheme, in which I fixed percentage of the file system space is preallocated to inodes. When you grow the file system you get more inodes as well. It appears, from looking at several file systems, that the constant is one inode for each 4k disk block in the file system. -- Marc Auslander <marc@ibm.com>
shore@theory.tn.cornell.edu (Melinda Shore) (04/13/91)
In article <MARC.91Apr12090853@marc.watson.ibm.com> marc@watson.ibm.com (Marc Auslander) writes: >I believe that the AIXV3 jfs uses the BSD inode scheme, in which I >fixed percentage of the file system space is preallocated to inodes. >When you grow the file system you get more inodes as well. It >appears, from looking at several file systems, that the constant is >one inode for each 4k disk block in the file system. Not so. The BSD filesystem allows the administrator to specify how many datablock bytes per inode. On a Vax the default is 2048 bytes, although your mileage may vary. Also, you can't "grow" a filesystem, as a general rule (you can if you have disk labels and you want to extend the end, leaving the beginning cylinder where it is, and you don't care about overwriting the filesystem that follows the one you're growing). -- Software longa, hardware brevis Melinda Shore - Cornell Information Technologies - shore@theory.tn.cornell.edu
jonathan@cs.pitt.edu (Jonathan Eunice) (04/15/91)
marc@watson.ibm.com (Marc Auslander) writes:
I believe that the AIXV3 jfs uses the BSD inode scheme, in which I
fixed percentage of the file system space is preallocated to inodes.
When you grow the file system you get more inodes as well. It
appears, from looking at several file systems, that the constant is
one inode for each 4k disk block in the file system.
I too believe this to be so.
When the system was released, however, I was told by several sources
in IBM that inodes were dynamically allocated as needed. This does
not appear to be the case (not according to my tests, at least);
though they do appear to be extended when file systems are extended.
This is a lot better than many *nix implementations, but not nearly as
good as the previous claim.