There's no mount command involved in timing. It's simply copy of the same directory (with many small files to NFS share with and without sec=krb5 mount option. Vlad. On Fri, 2011-06-03 at 08:32 -0400, Trond Myklebust wrote: > On Fri, 2011-06-03 at 09:29 +0200, Vladimir Elisseev wrote: > > Hello, > > > > After using nfs3 with kerberos for a while I discovered very poor > > performance for some file operations like creation of files. There are > > two observations: > > - the overal nfs3 performance is good: for instance copying large files > > works fine > > - this poor performance is definitely related to kerberos as the same > > volume exported without sec=krb5 works ~10 times faster with creating > > files > > I'd appreciate if somebody can explain this behaviour? > > > > Below are some details about NFS server and client: > > server: > > - kernel 2.6.36 > > - export options rw,sec=krb5,no_root_squash,no_subtree_check > > - nfs-utils 1.2.3 > > > > client: > > - kernel 2.6.38 or 2.6.39 > > - mout options (from /proc/mounts): > > rw,nosuid,nodev,noatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5,mountaddr=192.168.1.219,mountvers=3,mountport=32767,mountproto=tcp,local_lock=none,addr=192.168.1.219 > > > > when the same volume exported without sec=krb5, the only option changes > > in /proc/mounts is sec=sys > > Can you please tell us a bit more about how you are measuring this? I > might expect a x10 performance difference if the workload is dominated > by the actual setting up of the RPCSEC_GSS session (i.e. you are timing > mount+create one file or something like that). If we're talking about a > workload where the RPCSEC_GSS negotiation can be neglected, however > (mount+create 100000 files), I wouldn't expect any measurable > performance impact from 'sec=krb'. > > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
