"Vladimir V. Saveliev" wrote: > > Hi > > Rutger Swarts wrote: > > > > > > Can you provide description of names and sizes of those files? > > > > The files are small (between 1894 and 3682) images that together make up a > > huge high-detail map. The names look like this: > > > > Map.xXXXXXX.yYYYYYY.gif > > > > where XXXXXX and YYYYYY are the x and y co�rdinates of the square on that > > map. The files where created by a shellscript that cut the big scans in > > small parts. It took about 2 days to run. > > > > > How were those files created? I mean were those files created at once or > > > the directory grew during long period of time? > > > > > > Thanks, > > > vs > > > > > > > Ok, this is known reiserfs problem. And I am not sure that anything can help here >but storing files inode data together with names in > directory (which we are going to try someday). > > So, I guess that what happens is: > ls -l reads a block of a directory and then stats every name from that block. As >files are spread over whole disk > and as those files are ~2.5k long - then to stat all those files requires to read a >lot of disk blocks. That is why wall clock time is that > big. > > Note, that if your files were smaller, such that more files could fit into one block >- then you could make a copy that directory, and on that > copy ls -l would work faster. But for that average size of file I do not think that >currently there is a way to make performance of ls -l too > much better. > > Thanks, > vs Ah, I see. You could turn off tails, which would increase space consumption but make ls faster I encourage you to try this and report the results. It could make it a lot faster.
Hans
