From: Alex Elder <elder@ieee.org>
To: "Yan, Zheng" <ukernel@gmail.com>
Cc: "Yan, Zheng" <zheng.z.yan@intel.com>,
ceph-devel <ceph-devel@vger.kernel.org>,
Sage Weil <sage@inktank.com>
Subject: Re: [PATCH 2/5] ceph: remove zero-size xattr
Date: Tue, 11 Feb 2014 11:25:28 -0600 [thread overview]
Message-ID: <52FA5D08.6060108@ieee.org> (raw)
In-Reply-To: <CAAM7YAkrZ=r5qYHw8iwUHALa49DvjwABPwBd--izMv-CvH2OVQ@mail.gmail.com>
On 02/11/2014 09:10 AM, Yan, Zheng wrote:
> On Tue, Feb 11, 2014 at 10:47 PM, Alex Elder <elder@ieee.org> wrote:
>> On 02/10/2014 11:30 PM, Yan, Zheng wrote:
>>> Signed-off-by: Yan, Zheng <zheng.z.yan@intel.com>
>>
>> You really need to explain better under what circumstances
>> a zero-size xattr is getting removed.
>>
>> But apparently it's only when you're updating an xattr
>> (not building it up from a blob from storage).
>>
>> Why are you doing this? Why can't an xattr exist with
>> an empty value?
>
> That is how other FS behave, at least for ext* and btrfs.
I haven't tested this, I'm just glancing through code.
But it looks to me like a zero-length value is OK, but
a null value pointer means it should be deleted. Note
in btrfs_setxattr(), for example, the same bit of code
I referenced before:
if (size == 0)
value = ""; /* empty EA, do not remove */
And ext4 seems to delete for a null value, but handle
an xattr whose value *length* is zero. Same with XFS.
So again, I haven't verified through testing, but my
reading of the code (though rusty) still seems to show
that an attribute can have an empty (zero-size) value.
-Alex
> Regards
> Yan, Zheng
>
>>
>> Looking at generic_setxattr() in "fs/xattr.c" we see:
>> if (size == 0)
>> value = ""; /* empty EA, do not remove */
>>
>> The code you have below looks OK, but it seems that you
>> shouldn't be doing this.
>>
>> Am I missing something?
>>
>> -Alex
>>
>>> ---
>>> fs/ceph/xattr.c | 9 +++++++++
>>> 1 file changed, 9 insertions(+)
>>>
>>> diff --git a/fs/ceph/xattr.c b/fs/ceph/xattr.c
>>> index 28f9793..6ed0e5a 100644
>>> --- a/fs/ceph/xattr.c
>>> +++ b/fs/ceph/xattr.c
>>> @@ -12,6 +12,9 @@
>>> #define XATTR_CEPH_PREFIX "ceph."
>>> #define XATTR_CEPH_PREFIX_LEN (sizeof (XATTR_CEPH_PREFIX) - 1)
>>>
>>> +static int __remove_xattr(struct ceph_inode_info *ci,
>>> + struct ceph_inode_xattr *xattr);
>>> +
>>> /*
>>> * List of handlers for synthetic system.* attributes. Other
>>> * attributes are handled directly.
>>> @@ -359,6 +362,12 @@ static int __set_xattr(struct ceph_inode_info *ci,
>>> kfree(val);
>>> return err;
>>> }
>>> + if (!val_len) {
>>> + if (xattr)
>>> + __remove_xattr(ci, xattr);
>>> + kfree(name);
>>> + return 0;
>>> + }
>>> }
>>>
>>> if (!xattr) {
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-02-11 17:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-11 5:30 [PATCH 1/5] ceph: properly handle XATTR_CREATE and XATTR_REPLACE Yan, Zheng
2014-02-11 5:30 ` [PATCH 2/5] ceph: remove zero-size xattr Yan, Zheng
2014-02-11 14:47 ` Alex Elder
2014-02-11 15:10 ` Yan, Zheng
2014-02-11 17:25 ` Alex Elder [this message]
2014-02-12 2:37 ` Yan, Zheng
2014-02-12 2:43 ` Sage Weil
2014-02-12 2:46 ` Yan, Zheng
2014-02-11 5:30 ` [PATCH 3/5] ceph: fix ceph_removexattr() Yan, Zheng
2014-02-11 14:50 ` Alex Elder
2014-02-11 5:30 ` [PATCH 4/5] ceph: add missing init_acl() for mkdir() and atomic_open() Yan, Zheng
2014-02-11 17:45 ` Alex Elder
2014-02-14 5:46 ` Guangliang Zhao
2014-02-14 6:07 ` Yan, Zheng
2014-02-14 6:12 ` Yan, Zheng
2014-02-14 13:08 ` Alex Elder
2014-02-11 5:30 ` [PATCH 5/5] ceph: fix ceph_set_acl() Yan, Zheng
2014-02-11 18:06 ` Alex Elder
2014-02-11 14:36 ` [PATCH 1/5] ceph: properly handle XATTR_CREATE and XATTR_REPLACE Alex Elder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52FA5D08.6060108@ieee.org \
--to=elder@ieee.org \
--cc=ceph-devel@vger.kernel.org \
--cc=sage@inktank.com \
--cc=ukernel@gmail.com \
--cc=zheng.z.yan@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.