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