Jean-Marc Saffroy wrote:
Hi Eric,
Thanks for your answers!
On Fri, 8 Dec 2006, Eric Mei wrote:
Speak the performance hit, it's not seriously tested yet. The impact
might different from system to system, the main overhead is CPU
cycles on crypting, and a little bit more network traffic. So on
systems with powerful CPUs or hardware encryption the situation might
not too bad. Just a guess though.
The CPU overhead of bulk data checksumming on servers should be quite
high; FWIW a simple test of sha1sum gives me 154 MB/s with my fairly
recent CPU. The additional cost (CPUs or HW crypto engines) required
to achieve good performance may be too high for most HPC users, at
least for regular access inside a cluster; it could be interesting to
enable or disable checksumming for classes of clients.
I've seen a little laptop running Solaris ZFS do checksumming at over a
1 GByte / sec. Probably finding the right algorithms is important here.
- is it mandatory to deploy a keytab on clients? I don't remember
having done that when testing AFS+krb5
Yes it's mandatory, this will add some burden to sysadmin. The reason
is a little bit involved, we hope root could always own valid secure
contexts, otherwise a failed callback RPC from server to client will
lead to the client be kicked out off cluster.
It sounds like an implementation problem that surfaces to the user.
:-/ Maybe the operations you mention should be possible with
unauthenticated clients?
This was a choice to force the mount command to be authenticated. If
AFS mounts without such a file or keys obtained otherwise, then they
allow mount without authentication.
- Peter -
_______________________________________________
Lustre-devel mailing list
[email protected]
https://mail.clusterfs.com/mailman/listinfo/lustre-devel
