Messages in this thread | | | Date | Thu, 24 Jun 1999 00:25:06 +0100 (GMT) | From | Riley Williams <> | Subject | Re: 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/
| |