[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Filesystem-local databases in mlocate



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: pgpAQj1JjdrzK.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]