On 9/15/2014 10:57 PM, Jon Stanley wrote: > Actually commercial filesystems like VxFS adhere to the whitelist (I > think, it's been forever since I touched VxFS on Linux - or Solaris > for that matter :D), so it's definitely possible to do.
OpenAFS has support for functionality the VxFS does not. In particular, process authentication groups. Without pag support much of that list goes away. The AFS mount point processing and other features might also require functionality outside the usual use cases. > I'm at home > right now, so I didn't have a built AFS close by to look at, but I > built it on a quick VM and the situation isn't quite as bad as you > think: The list varies by RHEL release. [details of symbols removed] > Just getting rid of the usage of these symbols from OpenAFS would go a > long ways to ensure compatibility within and between RHEL releases. > The script can be found at > http://people.redhat.com/jcm/el6/dup/docs/scripts/rhel6_kabi_check.py Thanks for the pointer. >> David Howell's has an in-kernel AFS kernel module but its behavior is >> sufficiently different from the OpenAFS kernel module as to be >> disruptive for end users. There were efforts to modify David's kmod to >> share the OpenAFS userland tools but those ran into insurmountable >> hurdles. I believe David is now in the process of writing his own >> userland tool chain. > > Cool, but would it be easy for an OpenAFS user to migrate to these, > and is the in-kernel AFS nearly as complete as OpenAFS? My immediate > guess would be no on both counts, but I'd love to hear otherwise :) Of course the answer is "no" on both counts. Hence the reason the switch would be disruptive. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
