Cheers, that 64 bytes is interesting. Do you get a perf benefit on access to the file, too? Is it affected by long filenames at all?

Accessing the data in a tiny file is a bit faster. No matter what size the file is, you need the inode to find the data. In the case of a tiny file, the data is right in the inode, so you're done. In the case of a larger file, the inode tells you what blocks contain the data, and you still have to go get them.

Long filenames don't affect this much. Filenames are stored in directories (not in the inode) and directories are hashed for quick lookup. A directory consists of "dirents" where a dirent is a filename and an inode number.

To go from a filename to the data in the file, here are the steps:

1) hash filename and obtain dirent from the directory containing the file

2) use the inode number in the dirent to index into the inode table and obtain the inode.

3) use the information in the inode to get the data blocks

Edward.

-----Original Message----- From: Steve Losen [mailto:scl@sasha.acc.virginia.edu] Sent: Thursday, February 14, 2002 3:46 PM To: toasters@mathworks.com Subject: Re: Block sizes

...

Also worthy of note, to date there is no way to modify the block size. It's hardcoded in wafl.

~JK

While we're on the subject of WAFL trivia, WAFL does not split a 4K block into fragments, so files always consume disk space in even multiples of 4K bytes.

However, if the length of a file is 64 bytes or less, then the file data is stored in the inode and no data blocks are consumed. WAFL uses the space in the inode that otherwise holds the data block list.

This is nice because most symbolic links are small enough to fit in the inode.

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

University of Virginia ITC Unix Support

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

University of Virginia ITC Unix Support