Filesystem-local databases in mlocate

[Axel Thimm]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070318/1cfb2ec9/attachment.sig>