Thanks to all...the answers speak for themselves.
==============================================================================
Original question:
==============================================================================
I'm wondering about directory byte size. Typically a new directory is
8192 bytes;
drwxr-xr-x 2 kbrown users 8192 Jul 2 1997 C/
At some point, it seems, if a certain number of files (or files of a
certain size) are placed in a directory the byte count increases. It
stays at this new level regardless of the removal of all directory
contents.
Besides being curious about this, it has given us a bit of a problem
when comparing an original file system to a copy of same - because the
directories created in the copy area will be 8192 bytes, not the
inflated number of bytes. Thus, a compare of a du listing shows
differences (which may be irrelevant).
==============================================================================
Answers:
==============================================================================
Brian_ONeill_at_uml.edu (Brian O'Neill)
A directory is nothing more than a special type of file, which maps
filenames to inodes - think of it as a two-dimensional array.
When a directory is created, it is allocated a disk block (512 bytes),
and two entries are already stored there - "." and "..". (I'm not sure
why you see new directories as 8k)
As more files are created in the directory, eventually the entries will
exceed the 512 bytes allocated, and another block is allocated, making
it 1024 bytes, and so forth.
When files are deleted, the space in the directory file is NOT freed -
it will simply get reused later. So directories only grow in size, never
shrink.
By copying a directory, you are simply creating a new directory
somewhere else, and copying the files to it. Therefore, the new
directory is created with the minimum size, and then expanded to
accomodate only those filenames/inodes that are stored in it at the time
- eliminating all the "holes" which existed in the old directory.
If you have a directory whose contents varied greatly in the past but
has stabilized, backing up, removing, and restoring the directory will
save on some disk space and speed up filename lookups, but generally
only marginally.
==============================================================================
bseymour_at_encore.com (Burch Seymour RTPS)
Directory entries are structures written sequentially to the directory
file (see /usr/include/dirent.h for details of the structure). When the
initial file size is used up, the file grows. Included in the
dirent is the length of THIS entry, meaning that entries can vary in
size. Why? Well when a file is deleted, rather than rebuild the whole
directory and move things around, they simply add the size of the
deleted entry to the previous entry and it apparently vanishes.
Here is a dump of a sample case. Directory a has three files, b,c, and d.
Look at word 7, you see 0c000100, the 0c (or 12) is the length of the
directory entry.
BLOCK WORD
0000000 0000 01ce0100 0c000100 2e000000 00540000 .............T..
0004 0c000200 2e2e0000 02ce0100 0c000100 ................
0008 62007374 03ce0100 0c000100 63007374 b.st........c.st
000c 04ce0100 d0010100 64007374 00000000 ........d.st....
0010 00000000 00000000 00000000 00000000 ................
Now we delete the middle file, c, and word 7 becomes 18000100, the
18 (or 24 decimal) is now the length which means the entry for b
has swallowed the entry for c, even though the entry remains.
BLOCK WORD
0000000 0000 01ce0100 0c000100 2e000000 00540000 .............T..
0004 0c000200 2e2e0000 02ce0100 18000100 ................
0008 62007374 03ce0100 0c000100 63007374 b.st........c.st
000c 04ce0100 d0010100 64007374 00000000 ........d.st....
When you copy a directory, the excess is squeezed out since the files
are recreated, rather than a byte-by-byte copy of the directory
since you need new inodes and such.
==============================================================================
ps: fantastic response time: less than 1 hour!
----------------------------------------------------------------------
Ken Brown / kbrown_at_trentu.ca / tel: (705)748-1540 / fax: (705)748-1635
----------------------------------------------------------------------
Received on Fri May 01 1998 - 17:00:41 NZST