On Sun, Mar 18, 2007 at 02:38:59PM +0100, Bernardo Innocenti wrote: > 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. Well, aren't you just arguing against your original proposal to move everything to NFSv4 and rely on the caching done by NFSv4? ;) > > 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. You should try and time GFS. When it drops the domain locks, no caching survives. > GFS is usually accessed through the same bus types of ordinary > filesystems, including SAS, fiber-channel and even SATA. And network block devices. > 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. You are trying to solve an easy-to-solve caching problem by requiring o usage of NFSv4 o high bandwidth of drives o gigabit ethernet o and more while the original poster mentioned he needs this for his wireless connection of his laptop ... -- Axel.Thimm at ATrpms.net
Attachment:
pgpQremfIyLzd.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
