Re: [nfsv4] xattr model in draft-naik-nfsv4-xattrs-01?

Casey Bodley <cbodley@gmail.com> Mon, 06 October 2014 18:26 UTC

Return-Path: <cbodley@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE771A87BF for <nfsv4@ietfa.amsl.com>; Mon, 6 Oct 2014 11:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8O9wkWx9JS9 for <nfsv4@ietfa.amsl.com>; Mon, 6 Oct 2014 11:26:22 -0700 (PDT)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 970061A87C3 for <nfsv4@ietf.org>; Mon, 6 Oct 2014 11:26:22 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id m15so7357772wgh.14 for <nfsv4@ietf.org>; Mon, 06 Oct 2014 11:26:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RGW1SQaei3xyWIsFfjLLu+V6VEUc9L+E8UzZyre8Qus=; b=fETwsM4It+LJPvjFpiIejlpXXaes7HLkoft491mfurMWwvetxhHoMSAl5SrZfVJkTH E6SOnAKz14bjLNspJXFqggk07xUmW+7rMcTd+n91qQwG9H3rFwOQ4n2nEp3NWl1aOVe0 ilxeLDR0YWVBilipfQNQ3WmY2ff5uzCY7DUrqgXjjai7hHOB9NjYrHMhvr0v2d2Hlt4v AwNhi2gDWYuIIYO5+R7AaLIPTl34wvLEbL5zfpTbEB3kXaKnHcfug9pYf/hOVSE30dK6 BGte2qw1n99AZD62An8LC5/fpeSOJiMLDu30S6V4rbWTSzsry3Fig1rpauVzXRgyTkg4 jw4g==
MIME-Version: 1.0
X-Received: by 10.180.73.210 with SMTP id n18mr14808333wiv.79.1412619981236; Mon, 06 Oct 2014 11:26:21 -0700 (PDT)
Received: by 10.216.242.196 with HTTP; Mon, 6 Oct 2014 11:26:21 -0700 (PDT)
In-Reply-To: <OF88F663C8.C237679D-ON88257D67.006E4B58-88257D67.0070FBCC@us.ibm.com>
References: <20141004161750.GA22828@lst.de> <OF88F663C8.C237679D-ON88257D67.006E4B58-88257D67.0070FBCC@us.ibm.com>
Date: Mon, 06 Oct 2014 14:26:21 -0400
Message-ID: <CAMeBU_0+=eydwS8AP7yRn3UQRSOHY9a0XhEB3qReWnmxD-GZPg@mail.gmail.com>
From: Casey Bodley <cbodley@gmail.com>
To: Manoj Naik <mnaik@us.ibm.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/nfsv4/F7rr1gvxjRGwCXFfbLhCjUVhAD4
Cc: Christoph Hellwig <hch@lst.de>, nfsv4@ietf.org
Subject: Re: [nfsv4] xattr model in draft-naik-nfsv4-xattrs-01?
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Oct 2014 18:26:28 -0000

On Sat, Oct 4, 2014 at 4:34 PM, Manoj Naik <mnaik@us.ibm.com> wrote:
> Christoph Hellwig <hch@lst.de> wrote on 10/04/2014 09:17:50 AM:
>> On the GETXATTR side you conflate the LISTXATTR operation with GETXATTR,
>> as well as adding a new bulk get one that isn't present in any OS API
>> I know.  Both the argument and return structures are basically entirely
>> different for the different cases.
>
> Agree that GETXATTR includes what is traditionally provided by listxattr()
> call. The idea was to limit the number of new operations provided to two -
> GETXATTR and SETXATTR. But if there is consensus, we don't have an issue
> with adding a LISTXATTR instead.
>
> I think the ability to get/set all xattrs of a given file
> (getallxattrs/setallxattrs?) is useful, especially for backup/restore
> programs. Granted that there isn't an OS API that exposes this, but perhaps
> there should be one? I know some backup utilities that work directly with a
> filesystem API to do this. Especially over NFS, I believe a single RPC that
> accomplishes this may be desirable. I know somebody on the list or at the
> IETF meeting asked for this specifically too.

The Windows system calls and kernel interfaces operate on linked lists
of extended attributes. You can see their interfaces in the msdn
documentation for ZwQueryEaFile/ZwSetEaFile and
IRP_MJ_QUERY_EA/IRP_MJ_SET_EA.