Hi Lucho,

Andreas is right on mark. The problem here is that when one user kicks 
off an ls -l or ls -R on a cluster file system *while other users are 
trying to get work done*, all those stat RPCs and lock reclamations can 
kill performance.

We're not interested in a "ls -lR" top 500, we're interested in making 
systems more usable, more tolerant to everyday user behaviors.

Regards,

Rob

Latchesar Ionkov wrote:
quoted text
> On 12/5/06, Andreas Dilger <adilger@clusterfs.com> wrote:
>> The primary goal (IMHO) of this syscall is to allow the filesystem
>> (primarily distributed cluster filesystems, but HFS and NTFS developers
>> seem on board with this too) to avoid tens to thousands of stat RPCs in
>> very common ls -R, find, etc. kind of operations.
> 
> I don't think that ls -R and find are that common cases that they need
> introduction of new operations in order to made them faster. On the
> other hand may be they are often being used to do microbenchmarks. If
> you goal is to make these filesystems look faster on microbenchmarks,
> then probably you have the right solution. For normal use, especially
> on clusters, I don't see any advantage of doing that.
> 
> Thanks,
>    Lucho
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html