On 10/13/2017 08:49 AM, Patrick O'Callaghan wrote: > On Fri, 2017-10-13 at 11:04 -0400, bruce wrote: >> Hey guys.. >> >> Couple of questions. (I'll split them in sep mail msgs..) >> >> 1) What's a good/easy/best approach to getting the max possible number >> of files for a drive. Isn't the inode count a "good" approximation for >> this. > > It's not an approximation, it's an upper limit (just remember that > directories and devices are also files and have inodes). Unless of > course you want to pack many small files in a single archive file. I agree. The inode count set when a filesystem is created is fixed and defines the maximum number of file entries permitted on that filesystem, regardless of the size of those items (for the most part--there are exceptions). This includes regular files, directories, device nodes, etc.--essentially anything that can be displayed via "ls". If you run out of inodes you can't store any NEW files on that filesystem--even if there is unused data space remaining. Existing files can grow and use that remaining space, but you can't create new files. A good analogy is to think of a filesystem as a drawer in a file cabinet. You get to put in "n" manila folders (the inodes) when you create the drawer (filesystem). The space in the drawer not taken up by the folders is the available data space. Folders that are empty are "unused inodes". You can keep stuffing data into the folders until you've filled the data space, but you cannot create any ones. You can rearrange the folders, such as putting a folder inside a folder (which makes the outer folder a directory), but you're still using the same "n" folders you started with. Note that each type of filesystem also has limits as to the number of entries in a given directory. I think ext2 has a limit of 16384 entries (inodes)/directory (can't recall offhand), so bumping up the number of inodes to handle large numbers of small files may not work out as the directories used on the filesystem may not be able to handle the number of inodes you create. You can get around that by having multiple levels of directories. This isn't necessarily a bad thing as having a single, flat directory can make search times excessive. This limit is the basis of the "bucketing" algorithms you've probably heard of being used by some programs such as caches and such. These are all just things to keep in mind. Your intended usage of the filesystem should govern how you should set it up and there isn't really any one, "right" way. Tuning systems is more of an art form than a set of fixed rules. After 40+ years of doing this, I still get confused at times (to be honest, probably more often than not). ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - "More hay, Trigger?" "No thanks, Roy. I'm stuffed!" - ---------------------------------------------------------------------- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
