lkml.org 
[lkml]   [1999]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: why is the size of a directory always 1024b ?
Hi there.

>> I can also report that on my 4k block systems, I never see
>> directories smaller than 4k in size, but that's (A) expected,
>> and (B) desired.

>> I can understand the viewpoint that says the "size" of a directory
>> is simply a count of the number of valid entries therein, but I
>> don't agree with it.

> and why not? it seems meaningless to see a directory size
> reported as 1024 while the actual size may be far below. only
> the filesystem algorithms can make sense out of it. why, then it
> would make sense to see all regular files with sizes multiples
> of blocksize. can you please explain why you desire it that way.

You're misunderstanding my comment, and thus producing an invalid
comparison there. A better equivalent for regular files would be to
say "OK, this file contains 175 records, each 40 bytes long, so report
its size as 175", and I think you will agree that such is totally
meaningless, whereas the currently reported size of 7,000 bytes means
something sensible.

I don't know the internal structure of other file system types, but I
*DO* know the internal structure of the MSDOS (and VFAT) file systems.
In both cases, the directory entry is a record 32 bytes in length, but
part of M$'s specification of the file system is that when a directory
is extended, it is always extended by enough records to fill a single
'cluster' (M$'s name, not mine), and the size of the cluster depends
on (A) the size of the file system, and (B) whether it is formatted
for a FAT-12, FAT-16 or FAT-32 file system.

Assuming we're using a system with 1k clusters, that means that all
directories on that system have multiples of 32 records in them, and
thus have sizes that are multiples of 1k in length, so they are quite
correctly shown with suchlike lengths.

I would assume that similar restrictions are placed on most other file
systems, simply because doing so simplifies the design of the file
system, and thus speeds up the access code.

Best wishes from Riley.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.049 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site