----- Original Message ----- From: "Chris Thompson" cet1@cus.cam.ac.uk To: "Tom "Mad Dog" Yergeau" MadDog@fool.com Cc: marty.johnson@erols.com; toasters@mathworks.com Sent: Wednesday, April 04, 2001 1:11 PM Subject: Re: Inodes a go go

MadDog@fool.com (Tom "Mad Dog" Yergeau) writes:

...

Okay, now I am really really confused.

Here's a summary of my understanding; maybe someone can point out where

I'm

...

off track.

1. WAFL blocks are 4 KB
2. Max # of inodes is one per 4 K block
3. Each directory, even an empty one, fills at least one block
4. But, up to 128 empty directories can be sqeezed into one block

1-3 are right, but not 4. An "empty" directory (they are never really

empty,

of course, as they have entries for "." and ".." in them) still occupies one 4 KB block in WAFL.

The *pointers* to 128 empty directories (or to anything else) can be

"squeezed

into one block".

Right. In other words, 128 *directory entries* can be squeezed into one 4K block. What's a directory entry? Basically all the "filenames" of the files in a directory... so you files named "foo", "mbox", etc. all have their names stored in the 4K data block of the parent directory. Now, directories also have names, so like files, their name is stored in the 4K block of the parent.

So, even directory takes up 4K, minimum. If a directory has MORE than 128 entries... like a directory with 128 subdirectories all at the same level... then it gets allocated about 4K block.

One neat thing you can do is create a directory, fill it with a million files, then delete them all and you can still wind up with a directory that is megabytes in size but empty. Or at least you could. I think deleteing files "off the end" of the directory entry will actually shrink the directory size now, but you can fool this by not deleteing every 128th file. There's no automatic compression of "empty" directory entries. Unless that has changed too. Haven't tested it in ages. :)

Bruce

Basic stuff here that most folks already know, but it might help some newbies understand what's going on.

Files and directories are stored in a volume (filesystem) using a table of inodes and a pool of data blocks. Each file and directory is represented by an inode, a 128 byte data structure. A data block is 4k and is used for storing file data. A data block is either unused (free) or is assigned to a file.

The number of inodes determines how many files and directories the volume can hold. The number of data blocks determines how much file data the volume can hold. You can increase the number of inodes in a volume with the maxfiles command, but that decreases the number of data blocks, since some data blocks must be reassigned to the inode table to enlarge it. You cannot decrease the size of the inode table except by destroying the volume and rebuilding it. Whenever you add a new disk to a volume, both the data block pool and the inode table are enlarged.

Each inode contains information about a file or directory, including:

owner (UID number) group (GID number) permission bits (read/write/execute for user/group/other) file type bits (regular file, directory, device, symlink, etc.) device id (identifies volume containing the file) quota tree id (identifies quota tree containing the file) file size (length of file in bytes) link count (number of hard links to the file) timestamps (data access time, data mod time, inode mod time) data block list (specifies which data blocks hold file contents)

For files up to 64 bytes long, the file data is stored in the inode in the space used for the data block list. This avoids consuming an entire 4k data block to hold just a few bytes.

Each inode is identified by an inode number, which can be thought of as an index into the inode table. An inode is accessed by calculating its offset in the table using its inode number.

In particular, an inode does NOT store the file name. The file name is stored in the parent directory.

A directory is just a file that contains of a list of directory entries called "dirents". A dirent consists of a file name and an inode number. Dirents are variable length depending on the length of the file name. To see a sorted list of the dirents in a directory, run "ls -ai"

When you access a file (or directory) the parent directory is read to find the dirent with the file name. Using the corresponding inode number, the inode for the file is located in the inode table.

A newly created directory contains two dirents for the file names "." and "..". The "." dirent has the directory's own inode number while ".." has the parent directory's inode number. So these are not just a notational convention; they actually exist. A data block is assigned to the directory to store these two dirents. So the new directory consumes 1 inode, 1 data block, and a dirent in the parent directory.

Steve Losen scl@virginia.edu phone: 804-924-0640

University of Virginia ITC Unix Support

One caveat to all of this is that the assumption that you can fit 128 items into a directory block is just wrong. You can fit 128 inodes into a single 4K data block but a directory entry is not an inode. A directory entry consists of the name of the file and a pointer to the inode. The number of directory entries that you can fit into a single 4K directory block is dependant on the length of the filenames you create.

Yeah, so like I even confused myself in the email I just sent out before I got this one. Exactly how many directory entries you get depends on how much data it takes up, which depends on the length of the file names. But, no matter what, you can't get more than 128 because every entry is a pointer to an inode. Except maybe for special files?

Bruce