> : You're building a filesystem in a filesystem to overcome your
> : "non-optimal" original file system.
>
> Please show me the design of a file system which can bring in multiple
> small files with a single seek and read. When you get done, you'll be
> looking at what I described.
Seek and read which files? If you want anything but all files, you're
probably out of lock. Again, you will have to seek if any of the
files are fragmented (which is the case with most fs).
> I think that maybe you thought the point was disk space.
Ok.
> It's not, it's a performance problem. Consider a directory with a
> lot of little files. Each of those little files costs in the 10s of
> milliseconds to read in. On your spiffy drives you described, I can
> read in 10MB in 10ms plus the seek.
In reality one would (in general) rarely need to read all the files -
at least, that's my gut feeling. One might very well want to see a
list of all the files which can be fainfully slow with Unix. Or, in
other words: 1) would be rarely used while 2 could be very useful in
the scenario that you give:
1) seek_and_read(fd, path)
2) seek_and_read(fd, path, file_name_regex)
And if file_name_regex is resonable complex (*b*, *cd?d.txt etc) you
will have to seek anyhow. I assume you don't want different ordering,
right?
/Allan
-- Allan M. Wind mailto:wind@sap-help.com Manager Information Systems phone: 781.359.9791 (general) Integration Associates, Inc. phone: 781.273.0195 ext. 205 (direct) 55 Cambridge Street, Suite 301 fax: 781.359.9789 Burlington, MA 01803 http://www.sap-help.com- 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/