Change Details

Since ZFS was developed for Solaris, Solaris style extended attributes (which I call named attributes, which is the NFSv4 name) are already implemented in OpenZFS. This VFS/KAPI interface presents a named attribute directory that is associated with a file object, which holds regular files that are the attributes. The directory is read with getdents(2) or getdirentries(2) and the attributes found in the directory with regular file I/O such as read(2), write(2), lseek(2) and ftruncate(2). This patch provides the changes to use this alternate KAPI to access and modify extended attributes through the FreeBSD VFS, as patched by commit 2ec2ba7e232d to main/freebsd-current. A few notes: - Since the named attribute directory is associated with a file object found under the same name in the directory tree, name caching must be disabled. - Two new flags called LOOKUP_NAMED_ATTR and V_NAMEDATTR are used to indicate that zfs_zaccess() must check permissions for the attributes. - The permission checking code in zfs_zaccess() that is used when the above flag(s) are set is cribbed directly from zfs_zaccess() in the Linux branch. (openzfs/module/os/linux/zfs/zfs_acl.c). - zfs_check_attrname() was not changed. It was simply moved up in the source file so that it could be called in zfs_freebsd_create(). The new named attribute KAPI is supported when the "xattr" property is set to "on"/"dir" (I think they are synonymous?). Setting "xattr" to "sa" or "off" disables it. If this is not felt to be sufficient, a new setting for the "xattr" property could be defined. Note that the extended attributes can be manipulated by either KAPI (this Solaris-like one or the FreeBSD/Linux extended attribute model). The only limitation is the size restriction enforced for extattr_get_[fd|file]() and extattr_set_[fd|file](). Storage of extended attributes does not change and this works fine for the "dir" version (but not the "sa" version, as noted above).

I've put the patch here first. Once this review is completed, I will take it over to OpenZFS and discuss it there, plus propose a pull request. Since ZFS was developed for Solaris, Solaris style extended attributes (which I call named attributes, which is the NFSv4 name) are already implemented in OpenZFS. This VFS/KAPI interface presents a named attribute directory that is associated with a file object, which holds regular files that are the attributes. The directory is read with getdents(2) or getdirentries(2) and the attributes found in the directory with regular file I/O such as read(2), write(2), lseek(2) and ftruncate(2). This patch provides the changes to use this alternate KAPI to access and modify extended attributes through the FreeBSD VFS, as patched by commit 2ec2ba7e232d to main/freebsd-current. A few notes: - Since the named attribute directory is associated with a file object found under the same name in the directory tree, name caching must be disabled. - Two new flags called LOOKUP_NAMED_ATTR and V_NAMEDATTR are used to indicate that zfs_zaccess() must check permissions for the attributes. - The permission checking code in zfs_zaccess() that is used when the above flag(s) are set is cribbed directly from zfs_zaccess() in the Linux branch. (openzfs/module/os/linux/zfs/zfs_acl.c). - zfs_check_attrname() was not changed. It was simply moved up in the source file so that it could be called in zfs_freebsd_create(). The new named attribute KAPI is supported when the "xattr" property is set to "on"/"dir" (I think they are synonymous?). Setting "xattr" to "sa" or "off" disables it. If this is not felt to be sufficient, a new setting for the "xattr" property could be defined. Note that the extended attributes can be manipulated by either KAPI (this Solaris-like one or the FreeBSD/Linux extended attribute model). The only limitation is the size restriction enforced for extattr_get_[fd|file]() and extattr_set_[fd|file](). Storage of extended attributes does not change and this works fine for the "dir" version (but not the "sa" version, as noted above).

I've put the patch here first. Once this review is completed, I will take it over to OpenZFS and discuss it there, plus propose a pull request. Since ZFS was developed for Solaris, Solaris style extended attributes (which I call named attributes, which is the NFSv4 name) are already implemented in OpenZFS. This VFS/KAPI interface presents a named attribute directory that is associated with a file object, which holds regular files that are the attributes. The directory is read with getdents(2) or getdirentries(2) and the attributes found in the directory with regular file I/O such as read(2), write(2), lseek(2) and ftruncate(2). This patch provides the changes to use this alternate KAPI to access and modify extended attributes through the FreeBSD VFS, as patched by commit 2ec2ba7e232d to main/freebsd-current. A few notes: - Since the named attribute directory is associated with a file object found under the same name in the directory tree, name caching must be disabled. - Two new flags called LOOKUP_NAMED_ATTR and V_NAMEDATTR are used to indicate that zfs_zaccess() must check permissions for the attributes. - The permission checking code in zfs_zaccess() that is used when the above flag(s) are set is cribbed directly from zfs_zaccess() in the Linux branch. (openzfs/module/os/linux/zfs/zfs_acl.c). - zfs_check_attrname() was not changed. It was simply moved up in the source file so that it could be called in zfs_freebsd_create(). The new named attribute KAPI is supported when the "xattr" property is set to "on"/"dir" (I think they are synonymous?). Setting "xattr" to "sa" or "off" disables it. If this is not felt to be sufficient, a new setting for the "xattr" property could be defined. Note that the extended attributes can be manipulated by either KAPI (this Solaris-like one or the FreeBSD/Linux extended attribute model). The only limitation is the size restriction enforced for extattr_get_[fd|file]() and extattr_set_[fd|file](). Storage of extended attributes does not change and this works fine for the "dir" version (but not the "sa" version, as noted above).