Re: [Pvfs2-developers] Inconsistency in xattr functions
Ben: I think the pvfs getxattr is fashioned after the getfattr command, not the xattr command, which is probably why you are seeing this difference. Becky On Fri, May 8, 2015 at 9:45 AM, Ben Collins be...@servergy.com wrote: I’m trying to switch from using sycall/kernel-driver to direct pvfs_*() functions. A major issue is that pvfs_getxattr() returns a length 1 byte longer than syscalls, as shown: svy@papp1:~$ sudo attr -l /srv/data/cyphre-v2/user0 Attribute cyphre.owner has a 6 byte value for /srv/data/cyphre-v2/user0 svy@papp1:~$ sudo ./attr-test /srv/data/cyphre-v2/user0 user.cyphre.owner is 7 bytes Note that 6 is the correct answer. It’s the length I set with setxattr(). The second program was a quick one I write using pvfs_getxattr() where as the first one is using the attr program, so it uses getxattr() syscall directly, and goes through the kernel driver. If I do something like: len = pvfs_getxattr(path, key, NULL, 0); len—; // True length buf = malloc(len); len = pvfs_getxattr(path, key, buf, len); I get data that is, technically, the right length, but truncated by one byte (last byte is ‘\0’). My assumption (without digging too deep) is that the pvfs function adds an extra byte to null terminate the buffer, but it definitely shouldn’t do this (keys, sure, but not values). Either way, this makes the pvfs wrapper incompatible with the posix functions. —— Ben Collins Cyphre Champion —— VP of Engineering Servergy, Inc. ___ Pvfs2-developers mailing list Pvfs2-developers@beowulf-underground.org http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers -- Becky Ligon Research Associate Clemson University Clemson, SC ___ Pvfs2-developers mailing list Pvfs2-developers@beowulf-underground.org http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
[Pvfs2-developers] Inconsistency in xattr functions
I’m trying to switch from using sycall/kernel-driver to direct pvfs_*() functions. A major issue is that pvfs_getxattr() returns a length 1 byte longer than syscalls, as shown: svy@papp1:~$ sudo attr -l /srv/data/cyphre-v2/user0 Attribute cyphre.owner has a 6 byte value for /srv/data/cyphre-v2/user0 svy@papp1:~$ sudo ./attr-test /srv/data/cyphre-v2/user0 user.cyphre.owner is 7 bytes Note that 6 is the correct answer. It’s the length I set with setxattr(). The second program was a quick one I write using pvfs_getxattr() where as the first one is using the attr program, so it uses getxattr() syscall directly, and goes through the kernel driver. If I do something like: len = pvfs_getxattr(path, key, NULL, 0); len—; // True length buf = malloc(len); len = pvfs_getxattr(path, key, buf, len); I get data that is, technically, the right length, but truncated by one byte (last byte is ‘\0’). My assumption (without digging too deep) is that the pvfs function adds an extra byte to null terminate the buffer, but it definitely shouldn’t do this (keys, sure, but not values). Either way, this makes the pvfs wrapper incompatible with the posix functions. —— Ben Collins Cyphre Champion —— VP of Engineering Servergy, Inc. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Pvfs2-developers mailing list Pvfs2-developers@beowulf-underground.org http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
Re: [Pvfs2-developers] Inconsistency in xattr functions
Ben: I think those values are stored as a character string in both cases, the kernel version and our version; however, pvfs is not reporting the correct length, from a posix point of view. We will put that on our todo list. Thanks for bringing that to our attention, although, be aware that pvfs is not totally posix compliant and you may find other issues like this. Becky On Fri, May 8, 2015 at 9:45 AM, Ben Collins be...@servergy.com wrote: I’m trying to switch from using sycall/kernel-driver to direct pvfs_*() functions. A major issue is that pvfs_getxattr() returns a length 1 byte longer than syscalls, as shown: svy@papp1:~$ sudo attr -l /srv/data/cyphre-v2/user0 Attribute cyphre.owner has a 6 byte value for /srv/data/cyphre-v2/user0 svy@papp1:~$ sudo ./attr-test /srv/data/cyphre-v2/user0 user.cyphre.owner is 7 bytes Note that 6 is the correct answer. It’s the length I set with setxattr(). The second program was a quick one I write using pvfs_getxattr() where as the first one is using the attr program, so it uses getxattr() syscall directly, and goes through the kernel driver. If I do something like: len = pvfs_getxattr(path, key, NULL, 0); len—; // True length buf = malloc(len); len = pvfs_getxattr(path, key, buf, len); I get data that is, technically, the right length, but truncated by one byte (last byte is ‘\0’). My assumption (without digging too deep) is that the pvfs function adds an extra byte to null terminate the buffer, but it definitely shouldn’t do this (keys, sure, but not values). Either way, this makes the pvfs wrapper incompatible with the posix functions. —— Ben Collins Cyphre Champion —— VP of Engineering Servergy, Inc. ___ Pvfs2-developers mailing list Pvfs2-developers@beowulf-underground.org http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers -- Becky Ligon Research Associate Clemson University Clemson, SC ___ Pvfs2-developers mailing list Pvfs2-developers@beowulf-underground.org http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
