Fw: [OpenAFS-devel] openafs / opendfs collaboration
Steven French
sfrench@us.ibm.com
Thu, 20 Jan 2005 15:45:29 -0600
This is a multipart message in MIME format.
--=_alternative 007785E886256F8F_=
Content-Type: text/plain; charset="US-ASCII"
> is it time to consider splitting the cache manager out of individual
filesystem clients?
> If the interfaces are abstract enough, we should be able to have
multiple
> distributed fs's using the same cache manager API. Yes, there's tons of
> little details to be worked out (e.g. credential management, access
> control, etc.)
I am pleased with the recent addition of the credential keyring to the
kernel, thanks to AFS users, which will be helpful as soon as I figure out
what the user space tools are saving there at logon time - and how to hook
in kernel the plaintext password or kerberos ticket that winbind or
pam_kerberos get at logon (CIFS client has to get Kerberos tickets to
authenticate to Samba, Windows, Netapp etc.). I don't want to be
prompting for passwords as CIFS users traverse a DFS junction.
The credential management needs improvement in the kernel to handle CIFS,
NFSv4 and AFS (very similar problems) but the other parts o you comment is
puzzling, since at least for Linux the client cache is common (for all but
two major filesystems) and led to much of the improvement between 2.4 and
2.6 Linux kernels (and there is no distinct server cache as all of the
servers run on stock filesystems). CIFS client, NFS client etc. all use
the common mm cache and the CIFS client handles the primitive delegations
(oplock), somewhat similar to what NFSv4 will be doing. The in kernel
AFS client offerred a client cache to disk patch IIRC which would be
mildly helpful for everyone to standardize on - and I will be happy to
integrate support for that on the CIFS client side.
Where we could really use improvement is mapping the missing pieces of the
server side of the AFS API to a set of generic operations - to construct a
list of what is needed to be added to the kernel VFS so JFS, EXT3, XFS
etc. can replicate, move, backup, snapshot etc. better. There has been
enormous progress in the 2.6 kernel, but Samba 4, NFSv4 have protocol
support (which currently can not be implemented) that could plug into many
of these already.
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
--=_alternative 007785E886256F8F_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2><tt>> is it time to consider splitting the cache manager
out of individual filesystem clients?<br>
> If the interfaces are abstract enough, we should be able to have multiple<br>
> distributed fs's using the same cache manager API. Yes, there's
tons of<br>
> little details to be worked out (e.g. credential management, access<br>
> control, etc.) </tt></font>
<br>
<br><font size=2><tt>I am pleased with the recent addition of the credential
keyring to the kernel, thanks to AFS users, which will be helpful as soon
as I figure out what the user space tools are saving there at logon time
- and how to hook in kernel the plaintext password or kerberos ticket that
winbind or pam_kerberos get at logon (CIFS client has to get Kerberos tickets
to authenticate to Samba, Windows, Netapp etc.). I don't want to
be prompting for passwords as CIFS users traverse a DFS junction.</tt></font>
<br>
<br><font size=2><tt>The credential management needs improvement in the
kernel to handle CIFS, NFSv4 and AFS (very similar problems) but the other
parts o you comment is puzzling, since at least for Linux the client cache
is common (for all but two major filesystems) and led to much of the improvement
between 2.4 and 2.6 Linux kernels (and there is no distinct server cache
as all of the servers run on stock filesystems). CIFS client, NFS
client etc. all use the common mm cache and the CIFS client handles the
primitive delegations (oplock), somewhat similar to what NFSv4 will be
doing. The in kernel AFS client offerred a client cache to disk
patch IIRC which would be mildly helpful for everyone to standardize on
- and I will be happy to integrate support for that on the CIFS client
side.</tt></font>
<br>
<br><font size=2><tt>Where we could really use improvement is mapping the
missing pieces of the server side of the AFS API to a set of generic operations
- to construct a list of what is needed to be added to the kernel VFS so
JFS, EXT3, XFS etc. can replicate, move, backup, snapshot etc. better.
There has been enormous progress in the 2.6 kernel, but Samba 4,
NFSv4 have protocol support (which currently can not be implemented) that
could plug into many of these already.</tt></font>
<br><font size=2 face="sans-serif"><br>
<br>
Steve French<br>
Senior Software Engineer<br>
Linux Technology Center - IBM Austin<br>
phone: 512-838-2294<br>
email: sfrench at-sign us dot ibm dot com</font>
--=_alternative 007785E886256F8F_=--