extended attributes wiredness

extended attributes wiredness

[David Arendt]

Hi,

I am using kernel 3.7-rc6.

I have written a test application for extended attributes and have for
some folders a wired behaviour:

#include <stdio.h>
#include <string.h>
#include <attr/xattr.h>

char attrs[1024];
ssize_t attrslen;
int i;
char value[1024];
ssize_t valuelen;

int main(int argc, char *argv[])
{
  if (argc != 2)
  {
    fprintf(stderr, "Syntax: testxattr <filename>\n");

    return 1;
  }

  printf("processing file %s\n", argv[1]);

  attrslen = llistxattr(argv[1], attrs, 1024);

  if (attrslen < 0)
  {
    perror("listxattr failed");

    return 1;
  }

  for (i = 0; i < attrslen; i+= strlen(&attrs[i]) + 1)
  {
    printf("processing attribute %s\n", &attrs[i]);

    valuelen = lgetxattr(argv[1], &attrs[i], value, 1024);

    if (valuelen < 0);
    {
      perror("lgetxattr failed");

      return 1;
    }

    printf("value %.*s", (int) valuelen, value);
  }

  return 0;
}

is returning:

processing file /u00/root.20121121.210102.full/var/lib/nfs/sm
processing attribute system.posix_acl_default
lgetxattr failed: No data available

output of stat:

File: '/u00/root.20121121.210102.full/var/lib/nfs/sm'
Size: 94            Blocks: 0          IO Block: 4096   directory
Device: 3ah/58d    Inode: 1331353     Links: 1
Access: (0755/drwxr-xr-x)  Uid: (65534/  nobody)   Gid: (    0/    root)
Access: 2012-10-18 21:25:11.350000993 +0200
Modify: 2012-11-21 06:32:24.050210417 +0100
Change: 2012-11-21 06:32:24.050210417 +0100
Birth: -

Is this a bug in btrfs or do I miss something here ?

Thanks in advance,
David Arendt

Re: extended attributes wiredness

[Garry T. Williams]

On Friday, November 23, 2012 18:45:04 David Arendt wrote:
>   for (i = 0; i < attrslen; i+= strlen(&attrs[i]) + 1)
>   {
>     printf("processing attribute %s\n", &attrs[i]);
> 
>     valuelen = lgetxattr(argv[1], &attrs[i], value, 1024);
> 
>     if (valuelen < 0);
  Hmmm ----------------^



-- 
Garry T. Williams

Re: extended attributes wiredness

[David Arendt]

Well, this is only code to demonstrate the problem, the ; is normally a
silly mistake, but for my test case valuelen is < 0 so, the ; doesn't
change anything. With this corrected, the problem stays the same.

On 11/23/12 21:43, Garry T. Williams wrote:
> On Friday, November 23, 2012 18:45:04 David Arendt wrote:
>>   for (i = 0; i < attrslen; i+= strlen(&attrs[i]) + 1)
>>   {
>>     printf("processing attribute %s\n", &attrs[i]);
>>
>>     valuelen = lgetxattr(argv[1], &attrs[i], value, 1024);
>>
>>     if (valuelen < 0);
>   Hmmm ----------------^
>
>
>

Re: extended attributes wiredness

[Liu Bo]

On Fri, Nov 23, 2012 at 10:09:16PM +0100, David Arendt wrote:
> Well, this is only code to demonstrate the problem, the ; is normally a
> silly mistake, but for my test case valuelen is < 0 so, the ; doesn't
> change anything. With this corrected, the problem stays the same.
> 
> On 11/23/12 21:43, Garry T. Williams wrote:
> > On Friday, November 23, 2012 18:45:04 David Arendt wrote:
> >>   for (i = 0; i < attrslen; i+= strlen(&attrs[i]) + 1)
> >>   {
> >>     printf("processing attribute %s\n", &attrs[i]);
> >>
> >>     valuelen = lgetxattr(argv[1], &attrs[i], value, 1024);
> >>
> >>     if (valuelen < 0);
> >   Hmmm ----------------^

Hi David,

Any dmesg output for this?

thanks,
liubo

> >
> >
> >
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: extended attributes wiredness

[David Arendt]

Hi,

There is no dmesg output.

Thanks in advance,
David Arendt

On 11/24/12 04:39, Liu Bo wrote:
> On Fri, Nov 23, 2012 at 10:09:16PM +0100, David Arendt wrote:
>> Well, this is only code to demonstrate the problem, the ; is normally a
>> silly mistake, but for my test case valuelen is < 0 so, the ; doesn't
>> change anything. With this corrected, the problem stays the same.
>>
>> On 11/23/12 21:43, Garry T. Williams wrote:
>>> On Friday, November 23, 2012 18:45:04 David Arendt wrote:
>>>>   for (i = 0; i < attrslen; i+= strlen(&attrs[i]) + 1)
>>>>   {
>>>>     printf("processing attribute %s\n", &attrs[i]);
>>>>
>>>>     valuelen = lgetxattr(argv[1], &attrs[i], value, 1024);
>>>>
>>>>     if (valuelen < 0);
>>>   Hmmm ----------------^
> Hi David,
>
> Any dmesg output for this?
>
> thanks,
> liubo
>
>>>
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: extended attributes wiredness

[David Arendt]

Hi,

I have made some more tests:

./testxattr /u00/root.20121121.210102.full/var/lib/nfs/sm
processing file /u00/root.20121121.210102.full/var/lib/nfs/sm
processing attribute system.posix_acl_default
lgetxattr failed: No data available

getfattr /u00/root.20121121.210102.full/var/lib/nfs/sm
(no result)

setfattr -x system.posix_acl_default
/u00/root.20121121.210102.full/var/lib/nfs/sm

testxattr /u00/root.20121121.210102.full/var/lib/nfs/sm
processing file /u00/root.20121121.210102.full/var/lib/nfs/sm
processing attribute system.posix_acl_access

setfattr -x system.posix_acl_access
/u00/root.20121121.210102.full/var/lib/nfs/sm

./testxattr /u00/root.20121121.210102.full/var/lib/nfs/sm
processing file /u00/root.20121121.210102.full/var/lib/nfs/sm

Now a test with a manually set attribute:

setfattr -n user.testattribute -v testvalue
/u00/root.20121121.210102.full/var/lib/nfs/sm

getfattr /u00/root.20121121.210102.full/var/lib/nfs/sm
getfattr: Removing leading '/' from absolute path names
# file: u00/root.20121121.210102.full/var/lib/nfs/sm
user.testattribute

./testxattr /u00/root.20121121.210102.full/var/lib/nfs/smprocessing file
/u00/root.20121121.210102.full/var/lib/nfs/sm
processing attribute user.testattribute
value testvalue

Thanks in advance,
David Arendt

On 11/24/12 04:39, Liu Bo wrote:
> On Fri, Nov 23, 2012 at 10:09:16PM +0100, David Arendt wrote:
>> Well, this is only code to demonstrate the problem, the ; is normally a
>> silly mistake, but for my test case valuelen is < 0 so, the ; doesn't
>> change anything. With this corrected, the problem stays the same.
>>
>> On 11/23/12 21:43, Garry T. Williams wrote:
>>> On Friday, November 23, 2012 18:45:04 David Arendt wrote:
>>>>   for (i = 0; i < attrslen; i+= strlen(&attrs[i]) + 1)
>>>>   {
>>>>     printf("processing attribute %s\n", &attrs[i]);
>>>>
>>>>     valuelen = lgetxattr(argv[1], &attrs[i], value, 1024);
>>>>
>>>>     if (valuelen < 0);
>>>   Hmmm ----------------^
> Hi David,
>
> Any dmesg output for this?
>
> thanks,
> liubo
>
>>>
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: extended attributes wiredness

[Liu Bo]

On Sun, Nov 25, 2012 at 09:15:06PM +0100, David Arendt wrote:
> Hi,
> 
> I have made some more tests:
> 
> ./testxattr /u00/root.20121121.210102.full/var/lib/nfs/sm
> processing file /u00/root.20121121.210102.full/var/lib/nfs/sm
> processing attribute system.posix_acl_default
> lgetxattr failed: No data available
> 
> getfattr /u00/root.20121121.210102.full/var/lib/nfs/sm
> (no result)
> 
> setfattr -x system.posix_acl_default
> /u00/root.20121121.210102.full/var/lib/nfs/sm
> 
> testxattr /u00/root.20121121.210102.full/var/lib/nfs/sm
> processing file /u00/root.20121121.210102.full/var/lib/nfs/sm
> processing attribute system.posix_acl_access
> 
> setfattr -x system.posix_acl_access
> /u00/root.20121121.210102.full/var/lib/nfs/sm
> 
> ./testxattr /u00/root.20121121.210102.full/var/lib/nfs/sm
> processing file /u00/root.20121121.210102.full/var/lib/nfs/sm
> 
> Now a test with a manually set attribute:
> 
> setfattr -n user.testattribute -v testvalue
> /u00/root.20121121.210102.full/var/lib/nfs/sm
> 
> getfattr /u00/root.20121121.210102.full/var/lib/nfs/sm
> getfattr: Removing leading '/' from absolute path names
> # file: u00/root.20121121.210102.full/var/lib/nfs/sm
> user.testattribute
> 
> ./testxattr /u00/root.20121121.210102.full/var/lib/nfs/smprocessing file
> /u00/root.20121121.210102.full/var/lib/nfs/sm
> processing attribute user.testattribute
> value testvalue

So another manually set attribute proves the code is right, that means
the previous weird case is likely due to xattr metadata corruption somehow,
it maybe name hash mismatch, or the xattr name len mismatch.

thanks,
liubo

> 
> Thanks in advance,
> David Arendt
> 
> On 11/24/12 04:39, Liu Bo wrote:
> > On Fri, Nov 23, 2012 at 10:09:16PM +0100, David Arendt wrote:
> >> Well, this is only code to demonstrate the problem, the ; is normally a
> >> silly mistake, but for my test case valuelen is < 0 so, the ; doesn't
> >> change anything. With this corrected, the problem stays the same.
> >>
> >> On 11/23/12 21:43, Garry T. Williams wrote:
> >>> On Friday, November 23, 2012 18:45:04 David Arendt wrote:
> >>>>   for (i = 0; i < attrslen; i+= strlen(&attrs[i]) + 1)
> >>>>   {
> >>>>     printf("processing attribute %s\n", &attrs[i]);
> >>>>
> >>>>     valuelen = lgetxattr(argv[1], &attrs[i], value, 1024);
> >>>>
> >>>>     if (valuelen < 0);
> >>>   Hmmm ----------------^
> > Hi David,
> >
> > Any dmesg output for this?
> >
> > thanks,
> > liubo
> >
> >>>
> >>>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: extended attributes wiredness

[David Arendt]

Hi,

I don't know if your xattr patch was meant to fix this issue, but I have
just tested kernel 3.7-rc7 with your patch applied on another directory
having the problem and I still have the weird behaviour.

Thanks in advance,
David Arendt

On 11/26/12 03:54, Liu Bo wrote:
> On Sun, Nov 25, 2012 at 09:15:06PM +0100, David Arendt wrote:
>> Hi,
>>
>> I have made some more tests:
>>
>> ./testxattr /u00/root.20121121.210102.full/var/lib/nfs/sm
>> processing file /u00/root.20121121.210102.full/var/lib/nfs/sm
>> processing attribute system.posix_acl_default
>> lgetxattr failed: No data available
>>
>> getfattr /u00/root.20121121.210102.full/var/lib/nfs/sm
>> (no result)
>>
>> setfattr -x system.posix_acl_default
>> /u00/root.20121121.210102.full/var/lib/nfs/sm
>>
>> testxattr /u00/root.20121121.210102.full/var/lib/nfs/sm
>> processing file /u00/root.20121121.210102.full/var/lib/nfs/sm
>> processing attribute system.posix_acl_access
>>
>> setfattr -x system.posix_acl_access
>> /u00/root.20121121.210102.full/var/lib/nfs/sm
>>
>> ./testxattr /u00/root.20121121.210102.full/var/lib/nfs/sm
>> processing file /u00/root.20121121.210102.full/var/lib/nfs/sm
>>
>> Now a test with a manually set attribute:
>>
>> setfattr -n user.testattribute -v testvalue
>> /u00/root.20121121.210102.full/var/lib/nfs/sm
>>
>> getfattr /u00/root.20121121.210102.full/var/lib/nfs/sm
>> getfattr: Removing leading '/' from absolute path names
>> # file: u00/root.20121121.210102.full/var/lib/nfs/sm
>> user.testattribute
>>
>> ./testxattr /u00/root.20121121.210102.full/var/lib/nfs/smprocessing file
>> /u00/root.20121121.210102.full/var/lib/nfs/sm
>> processing attribute user.testattribute
>> value testvalue
> So another manually set attribute proves the code is right, that means
> the previous weird case is likely due to xattr metadata corruption somehow,
> it maybe name hash mismatch, or the xattr name len mismatch.
>
> thanks,
> liubo
>
>> Thanks in advance,
>> David Arendt
>>
>> On 11/24/12 04:39, Liu Bo wrote:
>>> On Fri, Nov 23, 2012 at 10:09:16PM +0100, David Arendt wrote:
>>>> Well, this is only code to demonstrate the problem, the ; is normally a
>>>> silly mistake, but for my test case valuelen is < 0 so, the ; doesn't
>>>> change anything. With this corrected, the problem stays the same.
>>>>
>>>> On 11/23/12 21:43, Garry T. Williams wrote:
>>>>> On Friday, November 23, 2012 18:45:04 David Arendt wrote:
>>>>>>   for (i = 0; i < attrslen; i+= strlen(&attrs[i]) + 1)
>>>>>>   {
>>>>>>     printf("processing attribute %s\n", &attrs[i]);
>>>>>>
>>>>>>     valuelen = lgetxattr(argv[1], &attrs[i], value, 1024);
>>>>>>
>>>>>>     if (valuelen < 0);
>>>>>   Hmmm ----------------^
>>> Hi David,
>>>
>>> Any dmesg output for this?
>>>
>>> thanks,
>>> liubo
>>>
>>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: extended attributes wiredness

[Liu Bo]

Hi,  
 
(cc btrfs Mailing list to notify others.)

Thanks for the helpful test.img.

Well...after deeper debug, I'm sure that it's not a btrfs bug,
at least not a btrfs acl/xattr bug. 
 
The debug tree shows 
 
item 10 key (257 INODE_ITEM 0) itemoff 3387 itemsize 160 
        inode generation 6 transid 6 size 102 block group 0 mode 40755 links 1 
item 11 key (257 INODE_REF 256) itemoff 3372 itemsize 15 
        inode ref index 2 namelen 5 name: test1 
item 12 key (257 XATTR_ITEM 367492571) itemoff 3318 itemsize 54 
        location key (0 UNKNOWN.0 0) type 8 
        namelen 24 datalen 0 name: system.posix_acl_default 
                  ^^^^^^^^^^^ 
item 13 key (257 XATTR_ITEM 2038346239) itemoff 3237 itemsize 81 
        location key (0 UNKNOWN.0 0) type 8 
        namelen 23 datalen 28 name: system.posix_acl_access 
        data ^B 
 
========== 

so extended attribute "system.posix_acl_default" here has not data, which'll
make filesystems(not just btrfs) return -ENODATA. 
 
I guess some userspace applications may make it like that. 
 
thanks, 
liubo

On Mon, Nov 26, 2012 at 06:38:06AM +0100, David Arendt wrote:
> Hi,
> 
> I don't know if your xattr patch was meant to fix this issue, but I have
> just tested kernel 3.7-rc7 with your patch applied on another directory
> having the problem and I still have the weird behaviour.
> 
> Thanks in advance,
> David Arendt

Re: extended attributes wiredness

[David Arendt]

Hi,

I tried to create an ext4 filesystem on a loop device and do a cp -a of
/var/lib/nfs/sm to the ext4 filesystem. Here the problem does not exist.
Perhaps ext4 has another behaviour in the sense that it doesn't store
empty attributes or doesn't return empty attributes.

I am using Gentoo and will try to do a new install on a loop device to
figure out which userspace program creates files this way.

Thanks in advance,
David Arendt

On 11/27/12 08:46, Liu Bo wrote:
> Hi,  
>  
> (cc btrfs Mailing list to notify others.)
>
> Thanks for the helpful test.img.
>
> Well...after deeper debug, I'm sure that it's not a btrfs bug,
> at least not a btrfs acl/xattr bug. 
>  
> The debug tree shows 
>  
> item 10 key (257 INODE_ITEM 0) itemoff 3387 itemsize 160 
>         inode generation 6 transid 6 size 102 block group 0 mode 40755 links 1 
> item 11 key (257 INODE_REF 256) itemoff 3372 itemsize 15 
>         inode ref index 2 namelen 5 name: test1 
> item 12 key (257 XATTR_ITEM 367492571) itemoff 3318 itemsize 54 
>         location key (0 UNKNOWN.0 0) type 8 
>         namelen 24 datalen 0 name: system.posix_acl_default 
>                   ^^^^^^^^^^^ 
> item 13 key (257 XATTR_ITEM 2038346239) itemoff 3237 itemsize 81 
>         location key (0 UNKNOWN.0 0) type 8 
>         namelen 23 datalen 28 name: system.posix_acl_access 
>         data ^B 
>  
> ========== 
>
> so extended attribute "system.posix_acl_default" here has not data, which'll
> make filesystems(not just btrfs) return -ENODATA. 
>  
> I guess some userspace applications may make it like that. 
>  
> thanks, 
> liubo
>
> On Mon, Nov 26, 2012 at 06:38:06AM +0100, David Arendt wrote:
>> Hi,
>>
>> I don't know if your xattr patch was meant to fix this issue, but I have
>> just tested kernel 3.7-rc7 with your patch applied on another directory
>> having the problem and I still have the weird behaviour.
>>
>> Thanks in advance,
>> David Arendt

Re: extended attributes wiredness

[David Arendt]

Hi,

I have now tested a gentoo reinstall with a recompile of nfs-utils. By
observing how the directory /var/lib/nfs is created, I found a rather
simple way to reproduce the problem:

dd if=/dev/zero of=test.img bs=8192 count=81920
81920+0 records in
81920+0 records out
671088640 bytes (671 MB) copied, 1.52943 s, 439 MB/s

losetup /dev/loop0 test.img

mkfs.btrfs /dev/loop0

WARNING! - Btrfs v0.20-rc1-37-g91d9eec IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

SMALL VOLUME: forcing mixed metadata/data groups
Created a data/metadata chunk of size 8388608
fs created label (null) on /dev/loop0
    nodesize 4096 leafsize 4096 sectorsize 4096 size 640.00MB
Btrfs v0.20-rc1-37-g91d9eec

mount /dev/loop0 /mnt

btrfs subvolume create /mnt/test
Create subvolume '/mnt/test'

mkdir /mnt/test/test1

/root/x/testxattr /mnt/test/test1 
processing file /mnt/test/test1

cp -a /mnt/test/test1 /mnt/test/test2

/root/x/testxattr /mnt/test/test2
processing file /mnt/test/test2
processing attribute system.posix_acl_default
lgetxattr failed: No data available

Might it be a bug in coreutils ?

Thanks in advance,
David Arendt

On 11/27/12 08:46, Liu Bo wrote:
> Hi,  
>  
> (cc btrfs Mailing list to notify others.)
>
> Thanks for the helpful test.img.
>
> Well...after deeper debug, I'm sure that it's not a btrfs bug,
> at least not a btrfs acl/xattr bug. 
>  
> The debug tree shows 
>  
> item 10 key (257 INODE_ITEM 0) itemoff 3387 itemsize 160 
>         inode generation 6 transid 6 size 102 block group 0 mode 40755 links 1 
> item 11 key (257 INODE_REF 256) itemoff 3372 itemsize 15 
>         inode ref index 2 namelen 5 name: test1 
> item 12 key (257 XATTR_ITEM 367492571) itemoff 3318 itemsize 54 
>         location key (0 UNKNOWN.0 0) type 8 
>         namelen 24 datalen 0 name: system.posix_acl_default 
>                   ^^^^^^^^^^^ 
> item 13 key (257 XATTR_ITEM 2038346239) itemoff 3237 itemsize 81 
>         location key (0 UNKNOWN.0 0) type 8 
>         namelen 23 datalen 28 name: system.posix_acl_access 
>         data ^B 
>  
> ========== 
>
> so extended attribute "system.posix_acl_default" here has not data, which'll
> make filesystems(not just btrfs) return -ENODATA. 
>  
> I guess some userspace applications may make it like that. 
>  
> thanks, 
> liubo
>
> On Mon, Nov 26, 2012 at 06:38:06AM +0100, David Arendt wrote:
>> Hi,
>>
>> I don't know if your xattr patch was meant to fix this issue, but I have
>> just tested kernel 3.7-rc7 with your patch applied on another directory
>> having the problem and I still have the weird behaviour.
>>
>> Thanks in advance,
>> David Arendt

Re: extended attributes wiredness

[David Arendt]

Hi,

based on my observations and debugging of the cp command, I have written
the following code to reproduce the problem:

#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/acl.h>

int main(int argc, char *argv[])
{
 acl_t acl;

 mkdir("test1", S_IRWXU);
 mkdir("test2", S_IRWXU);

 acl = acl_get_file("test1", ACL_TYPE_DEFAULT);

 if (acl == NULL)
 {
   perror("acl_get_file");

   return 1;
 }

 if (acl_set_file("test2", ACL_TYPE_DEFAULT, acl) < 0)
 {
   perror("acl_set_file");

   return 1;
 }

 return 0;
}

The code runs without any error.
On btrfs, attribute system.posix_acl_default is set but it contains no data.
On ext4, attribute system.posix_acl_default is not set.

Thanks in advance,
David Arendt

On 11/27/12 08:46, Liu Bo wrote:
> Hi,  
>  
> (cc btrfs Mailing list to notify others.)
>
> Thanks for the helpful test.img.
>
> Well...after deeper debug, I'm sure that it's not a btrfs bug,
> at least not a btrfs acl/xattr bug. 
>  
> The debug tree shows 
>  
> item 10 key (257 INODE_ITEM 0) itemoff 3387 itemsize 160 
>         inode generation 6 transid 6 size 102 block group 0 mode 40755 links 1 
> item 11 key (257 INODE_REF 256) itemoff 3372 itemsize 15 
>         inode ref index 2 namelen 5 name: test1 
> item 12 key (257 XATTR_ITEM 367492571) itemoff 3318 itemsize 54 
>         location key (0 UNKNOWN.0 0) type 8 
>         namelen 24 datalen 0 name: system.posix_acl_default 
>                   ^^^^^^^^^^^ 
> item 13 key (257 XATTR_ITEM 2038346239) itemoff 3237 itemsize 81 
>         location key (0 UNKNOWN.0 0) type 8 
>         namelen 23 datalen 28 name: system.posix_acl_access 
>         data ^B 
>  
> ========== 
>
> so extended attribute "system.posix_acl_default" here has not data, which'll
> make filesystems(not just btrfs) return -ENODATA. 
>  
> I guess some userspace applications may make it like that. 
>  
> thanks, 
> liubo
>
> On Mon, Nov 26, 2012 at 06:38:06AM +0100, David Arendt wrote:
>> Hi,
>>
>> I don't know if your xattr patch was meant to fix this issue, but I have
>> just tested kernel 3.7-rc7 with your patch applied on another directory
>> having the problem and I still have the weird behaviour.
>>
>> Thanks in advance,
>> David Arendt

Re: extended attributes wiredness

[Liu Bo]

On Tue, Nov 27, 2012 at 08:20:54PM +0100, David Arendt wrote:
> Hi,
> 
> I have now tested a gentoo reinstall with a recompile of nfs-utils. By
> observing how the directory /var/lib/nfs is created, I found a rather
> simple way to reproduce the problem:

Thanks for the reproduce steps, it helps quite a lot.

It turns out to be something wrong in btrfs's setting xattr code, I've
just sent you two patches for it, maybe you can check to see if it works
on your box :)

thanks,
liubo

Re: extended attributes wiredness

[Rock Lee]

Also reproduced on my computer.

The strace result:

sudo strace -s4096 -e trace=setxattr,getxattr cp -a test1 test2
getxattr("test1", "system.posix_acl_access", 0x7ffffab440d0, 132) = -1
ENODATA (No data available)
setxattr("test2", "system.posix_acl_access",
"\x02\x00\x00\x00\x01\x00\x07\x00\xff\xff\xff\xff\x04\x00\x05\x00\xff\xff\xff\xff
\x00\x05\x00\xff\xff\xff\xff", 28, 0) = 0
getxattr("test1", "system.posix_acl_default", 0x7ffffab440d0, 132) =
-1 ENODATA (No data available)
setxattr("test2", "system.posix_acl_default", "\x02\x00\x00\x00", 4, 0) = 0
+++ exited with 0 +++

Re: extended attributes wiredness

[David Arendt]

Hi,

your patches seem to fix the problem

Thanks,
David Arendt

On 11/28/12 11:54, Liu Bo wrote:
> On Tue, Nov 27, 2012 at 08:20:54PM +0100, David Arendt wrote:
>> Hi,
>>
>> I have now tested a gentoo reinstall with a recompile of nfs-utils. By
>> observing how the directory /var/lib/nfs is created, I found a rather
>> simple way to reproduce the problem:
> Thanks for the reproduce steps, it helps quite a lot.
>
> It turns out to be something wrong in btrfs's setting xattr code, I've
> just sent you two patches for it, maybe you can check to see if it works
> on your box :)
>
> thanks,
> liubo