Filesystem-local databases in mlocate

Axel Thimm Axel.Thimm at ATrpms.net
Sun Mar 18 17:33:12 UTC 2007


On Sun, Mar 18, 2007 at 03:52:14PM +0100, Bernardo Innocenti wrote:
> Axel Thimm wrote:
> >> And as of today I still find many trivial workloads for which
> >> NFSv4 still performs poorly.
> > 
> > Well, aren't you just arguing against your original proposal to move
> > everything to NFSv4 and rely on the caching done by NFSv4? ;)
> 
> :-) Telling the truth shall outweigh one's desire of being always
> right.

OK, but ...

> >> 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.

> It's been a while since I used GFS, and it was GFS1 on RHAS3 or
> maybe 4.  At that time, GFS performance was poor wrt ext3 even when
> the storage was locally attached to a single server.  But what it
> did was so useful for an HA cluster that you would excuse it for
> not being also fast.

... aren't you doing it again? On one post you assume GFS being as
fast as any local fs, only to admit that it isn't.

Anyway, seems at the end we do agree ;)

> > 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
> 
> Ouch... But these conditions were just ORed together!

Even so, what does the poor fellow with a laptop and NFS3 do? Which is
a very common setup?

> The reason I try to drive away from the caching solution is that
> most caches are more fragile and complex than their designers
> initially thought.  Most break in the face of the user who's not
> even aware of them (because caches are designed to be transparent).

In this case the caching is rather trivial, since it is just a copy
operation and checking sizes & mtime. It can be made _perfect_ by
adding a checksum at the beginning or end of the db.
-- 
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/9f39d108/attachment.sig>


More information about the fedora-devel-list mailing list