On Oct 28, 2013, at 9:39 PM, Christoph Anton Mitterer <calestyo@xxxxxxxxxxxx> wrote: > Trond,... since you ask for motivations pro NFS-XATTRs, I wondered what > are the strong reasons against? As I've already told you: you're asking for the addition of a feature which is inadequately defined, and is not documented in any standard. > Of course someone has to do the work,... but that's not really and > argument pro or con NFS-XATTRs, is it? > > The security problems with namespaces like trusted. or so can probably > be solved quite easy, e.g. simply by not supporting or > ignoring/rejecting them. > > You've mentioned caching issues,... could you elaborate a bit on that? > How is that much different from caching any other file metadata NFS > transfers? The standard metadata such as ctime, mtime, size, .... are all part of an existing NFS caching model called close-to-open. We know how they change when the filesystem data changes. How do I know when it is safe to cache your checksum xattr? I don't even know what it is, let alone what its relation is to the other filesystem objects. Let's say client B modifies the file and updates the checksum. When client A opens the file, it will see that the data has changed, but how does it know that it also needs to update the xattr information? Alternatively, let's say that client A reads the file and checksum data after client B has updated the file, but before it updates the checksum. What will cause client A to stop caching the stale checksum once client B has updated it? Trond-- 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
