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:
On 12/5/06, Andreas Dilger <adilger@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
