Branko Čibej wrote:
> Mark Mielke wrote:
>
>> Hyrum K. Wright wrote:
>>
>>> The basic benefit is the elimination of what I term "the inode
>>> problem" Any
>>> file on disk is physically stored on a set of sectors, which are of
>>> fixed size.
>>> It depends on the file system, but most sectors can not store parts
>>> of multiple
>>> files. *Every* file requires at least one sector, so if a file only
>>> contains 1
>>> byte of actual data, it still reserves an entire sector on disk
>>> (though again
>>> this varies by file system). The size of a sector may range from 512
>>> bytes to
>>> 32 kB or more. IIRC, ext3 uses 4 kB sectors.
>>>
>>>
>> The inode problem is a different problem - each file system often has
>> inode slots allocated up front, and if they become exhausted, no new
>> files can be created, even if the disk isn't fully in use.
>>
>
> Nah, that's just stupid ancient file systems; hardly better than the
> ancient 14-character filename length limit. XFS and a few others on
> Unix, NTFS, HFS+ and the like don't have that problem.
>
> You can bet that anyone who has a really big repository isn't hosting it
> on ext2 these days; Or as least if they do, it's some sysadmins should
> be shot.
>
> Block size overhead and directory sizes are the real issue here.
>
You sure you aren't making things up? :-) What's wrong with ext3? I
would bet ext3 is the most common in use for Linux platforms, and ext3
has inode limits. All file systems I can think of reserve administration
space for tracking purposes, and once the space is exhausted, problems
occur.
Cheers,
mark
--
Mark Mielke <mark_at_mielke.cc>
Received on 2008-11-28 23:21:08 CET