Filesystem-local databases in mlocate

[Bernardo Innocenti]

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/