Hi, Marc. At this point the agenda is full .. based on maximum time. But I am open to shifting things around a little if the other presenters are willing to adjust their time allotment. I suggest that you and I work this together off the cc'd aliases and you can send a summary when we work out the details. Spencer > -----Original Message----- > From: nfsv4-bounces@xxxxxxxx [mailto:nfsv4-bounces@xxxxxxxx] On Behalf > Of Marc Eshel > Sent: Monday, October 28, 2013 1:44 PM > To: spencer.shepler@xxxxxxxxx > Cc: Mailing List Linux NFS; Christoph Anton Mitterer; Myklebust, Trond; Steve > Dickson; nfsv4@xxxxxxxx; Dr Fields James Bruce; Ric Wheeler; linux-nfs- > owner@xxxxxxxxxxxxxxx > Subject: Re: [nfsv4] XATTRs in NFS? > > Hi Spencer, > Is it still possible to get on the agenda fir IETF 88, I just got approval to travel. > We can use about 15 minutes, or what ever is available to discussion the > future of named attributes in NFS. The two main questions that we need > answer are: > 1. Do we need them? what applications use them and how. > 2. Can we have a more simple model that handles just user attributes. > > Input is welcome to help me make the case at the meeting. > > Thanks, Marc. > > > > > From: Ric Wheeler <rwheeler@xxxxxxxxxx> > To: Dr Fields James Bruce <bfields@xxxxxxxxxxxx>, > Cc: "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx>, Christoph > Anton > Mitterer <calestyo@xxxxxxxxxxxx>, Mailing List Linux NFS <linux- > nfs@xxxxxxxxxxxxxxx>, Steve Dickson <SteveD@xxxxxxxxxx> > Date: 10/28/2013 11:32 AM > Subject: Re: XATTRs in NFS? > Sent by: linux-nfs-owner@xxxxxxxxxxxxxxx > > > > On 10/28/2013 02:08 PM, Dr Fields James Bruce wrote: > > On Mon, Oct 28, 2013 at 02:00:58PM -0400, Ric Wheeler wrote: > >> On 10/28/2013 01:49 PM, Myklebust, Trond wrote: > >>> On Oct 28, 2013, at 12:15 PM, Christoph Anton Mitterer > <calestyo@xxxxxxxxxxxx> wrote: > >>> > >>>> On Mon, 2013-10-28 at 11:40 -0400, Ric Wheeler wrote: > >>>>> Then you end up with large directories and an extra name per inode > that needs to > >>>>> be stored and extra lookups for each file when you do a whole file > system crawl. > >>>>> > >>>>> Certainly not as easy as adding and xattrs with that information :) > >>>> And I think there's another reason why it wouldn't work... > >>>> > >>>> Imagine I change my system to encode what should be XATTRs in > hardlink > >>>> pseudo files... > >>>> > >>>> If I have such pair locally e.g. on my ext4: > >>>> /foo/bar/actual/file > >>>> /meta/<SHA512 identifier>.2342348324 > >>>> > >>>> And now move/copy the file via the network to the archive, I'd have > to > >>>> copy both files (which is really annoying), and I'd guess the inode > >>>> coupling would get los (and at least the name wouldn't fit anymore). > >>>> > >>>> So the whole thing is IMHO not even a workaround. > >>> OK. So you're going to do XATTRs for us? > >>> > >>> Trond > >> Now that pNFS is perfect and labeled NFS has made it upstream, I > >> think that Steve D must be looking for something to keep him busy :) > > I agree with Trond that we first really need good evidence about exactly > > who wants this and why. > > > > --b. > > For the user space xattrs, many applications store various types of > metadata. > Gluster for example heavily uses xattrs, other programs do things like > data > scrubbing (look for a long unchanged file, compute a has and store it as > an > xattr) or simply use it to annotate the file with the name of the program > that > created it. Think of it as file decorations or annotations. > > Today, if we store files in NFS that have xattrs, we do in fact cause data > loss. > > I can understand an answer of "this would be hard to do for NFS and need > to go > through IETF" but think that xattrs are well enough established in Linux > and > supported in the tool chain that it is way too late to question whether or > not > supporting them is a worth our time. > > Ric > > -- > 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 > > > > _______________________________________________ > nfsv4 mailing list > nfsv4@xxxxxxxx > https://www.ietf.org/mailman/listinfo/nfsv4 -- 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
