Axel Thimm wrote: > With mlocate you will not really have a choice when it the changes are > applied, while with NFS it's an admin's choice to use NFS3 or NFSv4, > and 3 still has the larger share and will probably do so long after > mlocate introduces these changes. Both of which always have done a better job than NFSv3 with client-side caching. Even Samba is much better. As far as I can tell, NFSv4 is just catching up. And as of today I still find many trivial workloads for which NFSv4 still performs poorly. Try "time find /nfs_share >/dev/null" versus the same command on a local filesystem to see what I mean. > And NFS is not the only remote filesystem, nor the only filesystem in > general where this will be applied. Other prominent fs that will > benefit from this setup are GFS and openafs. Why would GFS be any slower than a non-clustered filesystem when it comes to raw data read performance? The DLM overhead would supposedly not get in the way of every single block being read. GFS is usually accessed through the same bus types of ordinary filesystems, including SAS, fiber-channel and even SATA. Even gigabit ethernet, which would be a very uncommon transport for block-level storage, would be fast enough for the bandwidth of today's ordinary hard drives. -- // Bernardo Innocenti - Develer R&D dept. \X/ http://www.develer.com/ -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
