Hi Trond, I am just trying to see if there any path here to get xattr over NFS. Assuming that there is agreement that xattr are used and needed, and we need to build a better case here but just give alternative solutions doesn't mean that is not needed, almost every thing can be done with an additional DB that associates attributes with files but it is not the best or right way. So if we had an NFS protocol extension (might not be named attributes) that mapped to and was semantically compatibly to Linux xattr, as Nico wrote, would that be enough to consider adding it to the Linux NFS? I see the need to show requirement and better interface over the NFS protocol (with no security holes) but not sure if we have another problem with standardizing xattr in Linux? Thanks, Marc. From: "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> To: Christoph Anton Mitterer <calestyo@xxxxxxxxxxxx>, Cc: Wheeler Ric <rwheeler@xxxxxxxxxx>, Anand Avati <aavati@xxxxxxxxxx>, "Dr Fields James Bruce" <bfields@xxxxxxxxxx>, Mailing List Linux NFS <linux-nfs@xxxxxxxxxxxxxxx>, Dickson Steve <steved@xxxxxxxxxx> Date: 10/28/2013 07:28 PM Subject: Re: XATTRs in NFS? Sent by: linux-nfs-owner@xxxxxxxxxxxxxxx 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 -- 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
