> In article <x74t3szrih.fsf@metal.iinet.net.au> you write:
> >While staring dejectedly at a filesystem holding a tad of 3 million
> >files, and looking at the 'orrible latency to open a file, it occured
> >to me that with most usage patterns, two things are true:
>
> How many of these files are actually accessed within an our? Or within
> a day?
About 100,000 per hour. There is some cache locality, but not
much. (The machine is running with around 300meg of ram as a disk
cache, and stays disk bound for about 60 - 70% of the time).
> >
> > 1) There are very few inodes that have more than one parent
> > (i.e. more than one filename pointing to them)
>
> No, a news spool of INN actually contains many hard links.
True, but a news spool is a very unusual file system anyway.
> > 3) On most modern hard disks, the cost of reading 4K as
> > opposed to reading 1K is minute (it's dominated by
> > seek times etc).
>
> It could actually speed up access. But I think prefetching is
> done already anyway, at various levels.
>
> >Then it occured to me that if you force aligning inodes on 64 byte
> >boundries, the addressable filesystem goes to 256gig (probably enough
> >for now).
>
> No. Terabyte disk arrays already exist, and terabyte disks and files
> will be there within a few years. If we ignore this we end up with
> a degenerate system like Windoze.
It doesn't limit the size of the filesystem, just requires that the
inodes lie in the first 1/4 terabyte or first 1/2 terabyte. Not
exactly a terrible restriction. :)
> >Comments?? (people dying to implement such a beast? :)
>
> I guess something should be done, but not this way. There are
> several new filesystems under construction. Perhaps one of these
> can implement some optimizations.
There are indeed a number under development, but I was more looking
for something that would be useable in the short term.
Ext2 is a nice fast filesystem. This is a relatively small change that
would hopefully make it faster yet, without noticeable cost.
Michael.