On Wed, Jun 25, 2008 at 09:02:42AM +0200, Adrian von Bidder wrote:
> On Tuesday 24 June 2008 22.29:31 J. Bruce Fields wrote:
> > On Tue, Jun 24, 2008 at 12:17:24PM +0200, Adrian von Bidder wrote:
>
> > > Starting KDE, opening documents, sometimes also closing oo.org and
> > > saving documents takes several seconds longer than on local disk.
> >
> > "close" on nfs is an operation that requires a round-trip to the server
> > and waiting for the disk to commit any writes made before the close, so
> > if you've got to do a lot of those it can take time. Fooling with the
> > journaling on the exported filesystem may help.
>
> Are there tools to measure latencies on NFS? Given a network dump, desired
> output would be histograms of latencies by file operation? (Or maybe I can
> catch the information on the client, VFS side instead of NFS?
>
> At this time, I really need to collect more data on where the problem is
> since all I'm doing right now is fooling around based on assumptions... :-(
>
> OTOH I'd suspect KDE/oo.org startup to be mostly reads of those config
> files, so the problem shouldn't be close latencies. Assumptions again.
>
> > > TODO today: play around with NFSv4 on the shaky assumption that nfsv3
> > > is actually working but net latency is killing my performance.
> >
> > Delegations *might* help if the problem is really open latency.
>
> First tries showed
> * There are no acl on my files now
NFSv4 uses an entirely different type of ACL, for which you need
different client-side tools; see
http://www.citi.umich.edu/projects/nfsv4/linux/nfs4-acl-tools/
> * user id mapping seems funny: some users map to nobody, others map
> correctly. Huh?
And whereas v2/v3 require only uid's and gid's to agree, v4 (if you're
using auth_sys) requires uid's, gid's, *and* user and group names to
agree.
--b.
> * Performance seems to be ok (timing desktop applications is always
> difficult, and so far I'm working against on the production server with
> varying load anyway...)
>
> Haven't investigated these yet...
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs
On Wednesday 25 June 2008 18.56:58 J. Bruce Fields wrote:
> On Wed, Jun 25, 2008 at 09:02:42AM +0200, Adrian von Bidder wrote:
> > On Tuesday 24 June 2008 22.29:31 J. Bruce Fields wrote:
> > > On Tue, Jun 24, 2008 at 12:17:24PM +0200, Adrian von Bidder wrote:
> > > > Starting KDE, opening documents, sometimes also closing oo.org and
> > > > saving documents takes several seconds longer than on local disk.
> > >
> > > "close" on nfs is an operation that requires a round-trip to the
> > > server and waiting for the disk to commit any writes made before the
> > > close, so if you've got to do a lot of those it can take time.
> > > Fooling with the journaling on the exported filesystem may help.
> >
> > Are there tools to measure latencies on NFS? Given a network dump,
> > desired output would be histograms of latencies by file operation? (Or
> > maybe I can catch the information on the client, VFS side instead of
> > NFS?
> >
> > At this time, I really need to collect more data on where the problem
> > is since all I'm doing right now is fooling around based on
> > assumptions... :-(
> >
> > OTOH I'd suspect KDE/oo.org startup to be mostly reads of those config
> > files, so the problem shouldn't be close latencies. Assumptions again.
> >
> > > > TODO today: play around with NFSv4 on the shaky assumption that
> > > > nfsv3 is actually working but net latency is killing my
> > > > performance.
> > >
> > > Delegations *might* help if the problem is really open latency.
> >
> > First tries showed
> > * There are no acl on my files now
>
> NFSv4 uses an entirely different type of ACL, for which you need
> different client-side tools; see
I'm absolutely confused on the state of nfs4 acls. There are so many old
mailing list posts around that it's difficult to see what information
applies to the currentimplementation. So: are POSIX acls in the server
filesystem somehow mapped to nfsv4 acls on the client side? I understand
there understands an RFC proposal on how to do this, and
http://wiki.linux-nfs.org/wiki/index.php/ACLs is very interesting but
doesn't really cover the current state of the implementation.
> http://www.citi.umich.edu/projects/nfsv4/linux/nfs4-acl-tools/
Hmm. Not packaged in Debian yet?????? ;-) So work to do for me if I end up
using nfs4
>
> > * user id mapping seems funny: some users map to nobody, others map
> > correctly. Huh?
>
> And whereas v2/v3 require only uid's and gid's to agree, v4 (if you're
> using auth_sys) requires uid's, gid's, *and* user and group names to
> agree.
I got that fixed. "localdomain" in idmapd.conf...
cheers
-- vbi
--
> Maybe that question would be a good starting point: What's the use for
> a gender field there?
Stalking.
-- Miriam Ruiz, Marco d'Itri (im that order)