extended attributes wiredness

DISCUSSION David Arendt 4 participants 15 messages Nov 23, 2012 – Nov 28, 2012 Btrfs file system

lore

Share & tools

lore

David Arendt

author

2012-11-23 17:45 UTC #0 lore raw

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

Garry T. Williams

2012-11-23 20:43 UTC #1 lore raw

Quoted 7 lines · 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 ----------------^

Signature · 1 line

Garry T. Williams

David Arendt

author

2012-11-23 21:09 UTC #2 lore raw

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.

Quoted 12 lines · Garry T. Williams

Quoted 7 lines · 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 ----------------^

Liu Bo

2012-11-24 03:39 UTC #3 lore raw

Quoted 4 lines · 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.

Quoted 10 lines

Quoted 9 lines · Garry T. Williams
Quoted 7 lines · 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

Quoted 8 lines

Quoted 3 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

David Arendt

author

2012-11-24 07:17 UTC #4 lore raw

Hi,

There is no dmesg output.

Thanks in advance,
David Arendt

Quoted 32 lines · Liu Bo

Quoted 4 lines · 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.
Quoted 10 lines
Quoted 9 lines · Garry T. Williams
Quoted 7 lines · 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
Quoted 6 lines
Quoted 2 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

David Arendt

author

2012-11-25 20:15 UTC #5 lore raw

In reply to Liu Bo

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

Quoted 32 lines · Liu Bo

Quoted 4 lines · 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.
Quoted 10 lines
Quoted 9 lines · Garry T. Williams
Quoted 7 lines · 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
Quoted 6 lines
Quoted 2 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Liu Bo

2012-11-26 02:57 UTC #6 lore raw

Quoted 35 lines · 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

Quoted 4 lines

./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

Quoted 42 lines

Thanks in advance,
David Arendt
Quoted 24 lines · Liu Bo
Quoted 4 lines · 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.
Quoted 10 lines
Quoted 9 lines · Garry T. Williams
Quoted 7 lines · 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
Quoted 2 lines
Quoted 2 lines
Quoted 8 lines
Quoted 4 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
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 [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

David Arendt

author

2012-11-26 05:38 UTC #7 lore raw

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

Quoted 86 lines · Liu Bo

Quoted 35 lines · 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
Quoted 4 lines
./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
Quoted 39 lines
Thanks in advance,
David Arendt
Quoted 23 lines · Liu Bo
Quoted 4 lines · 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.
Quoted 10 lines
Quoted 9 lines · Garry T. Williams
Quoted 7 lines · 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
Quoted 1 line
Quoted 1 line
Quoted 8 lines
Quoted 4 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
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 [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Liu Bo

2012-11-27 07:48 UTC #8 lore raw

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

Quoted 8 lines · 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

David Arendt

author

2012-11-27 16:53 UTC #9 lore raw

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

Quoted 43 lines · 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
Quoted 8 lines · 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

David Arendt

author

2012-11-27 19:21 UTC #10 lore raw

In reply to Liu Bo

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

Quoted 43 lines · 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
Quoted 8 lines · 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

David Arendt

author

2012-11-27 21:19 UTC #14 lore raw

In reply to Liu Bo

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

Quoted 43 lines · 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
Quoted 8 lines · 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

Liu Bo

2012-11-28 10:56 UTC #11 lore raw

In reply to David Arendt

Quoted 5 lines · 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:

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

Rock Lee

2012-11-28 11:13 UTC #12 lore raw

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 +++

David Arendt

author

2012-11-28 17:12 UTC #13 lore raw

In reply to Liu Bo

Hi,

your patches seem to fix the problem

Thanks,
David Arendt

Quoted 14 lines · Liu Bo

Quoted 5 lines · 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:
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