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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
