On Fri, Oct 04, 2013 at 11:39:54AM -0400, David Quigley wrote: > ( Adding linux-nfs to the list of people) > > Here is a summary of the discussion so far. > > Dan Walsh is seeing issues with Labeled NFS. The issue he is seeing > is that a label change on the server is not reflected on the client > until a remount of the client. There should be a delay in the label > change being reflected in the client as we don't yet have the label > change notification in. However it should only be until the cache > for the file attribute is invalidated and the next getfattr call > revalidates the label. It is unclear why a remount is needed at this > time. > > Bruce has expressed the concern that the label change notification > was not designed for this particular use case and the > protocol/implementation may need to be reworked. > > My understanding of the usecases discussed for Labeled NFS have > sVirt and NFS mounted home. Both of which will make label changes > quite often. Part of SVirt is support in libvirt to change the > category fields on the vm images to match that of the starting qemu > process. This gives the process separation that just using types > alone would make difficult. For home directories labels may change > all the time from a client perspective if another client is > modifying file labels. I think what we conveyed a while back (I > don't remember the conversation) is that a whole sale relabel of the > server from underneath the clients is unlikely to happen. However > there is definitely a real use case where client A modifies the > label on a file and Client B needs to see that. Without having full > support where the server enforces policy we're relying on the client > to enforce those policies which they can't reliably do without > knowing about the label change. One thing we had discussed in the > past though is that the cache timeout could be sufficient in the > situation where we lack the label change notification under the > assumption that if the file was opened with that label at least for > that short time it should still be ok for it to still read/write to > that file. There are situations where that is not ideal though. Its > not clear to me why the client is requiring a remount to get the > label change though. Upon cache invalidation another getfattr call > for the label should be sent and it should pull it back. I haven't actually checked, but I suspect we need to implement the label_change attribute (on both client and server) before that works well. --b. -- 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
