Native Extended Attributes and Cross-Compiling Haiku

Due to the various ways that extended attributes are implemented in various file systems, some will present issues that need to be considered and others will simply be unusable. This page aims to clarify which file systems have extended attribute implementations compatible enough with Haiku’s that they can be utilized during cross-builds.

Note that configure auto-detects the extended attribute capabilites of the filesystem you have asked it to configure a build on, and will automatically select “full”, “ref”, or no usage at all based on the filesystem’s capabilites. If you would like to check what it has selected, you can view the build/BuildConfig file in your generated directory, and check the values of HAIKU_HOST_USE_XATTR and HAIKU_HOST_USE_XATTR_REF.

Please keep in mind that best results are generally obtained by using a filesystem natively, as compared to using it via a userland implementation like FUSE. All filesystems listed below are assumed to be utilized natively, unless otherwise noted.

Compatible filesystems

• JFS

  (Note: JFS may exhibit instability and out-of-memory errors when --use-xattr is utilized.)

• NTFS (via NTFS-3G)

• ReiserFS

• UFS2

• XFS

• ZFS

Troublesome filesystems

• Btrfs

  Building Haiku on Btrfs with extended attributes does not work. Utilizing it will give an error like the following, which was encountered when building Poorman.

  mimeset: "/btrfs/haiku/haiku/generated.x86_gcc2/objects/haiku/x86/release/apps/poorman/PoorMan": No space left on device

  Btrfs will need to be explored again in the future as it matures, since currently it is still a fairly young filesystem.

• Ext2, Ext3, Ext4

  Ext has a limit of one block, which is typically 4KB for reasonably large volumes. Since all attributes of a file need to be stored in this single block, it often is not large enough. Specifically, Expander is one application that is known to fail compiling when the block size is 4KB or smaller.

  <mmu_man> it fails here on ext3 on Expander IIRC, which has many supported types = too large xattr & you need to explicitly enable it in fstab

• HFS+ (case sensitive)

  HFS+ fails just like Btrfs does, with a nearly identical error message.

  mimeset: "generated/objects/haiku/x86/release/apps/poorman/PoorMan": Argument list too long

Some Notes

• How can you check for xattr support?

  There are command line tools for setting/getting attributes. You can just try them on a file:

      touch tt
      setfattr -n "user.testAttr" -v "attribute value" tt
      getfattr -n "user.testAttr" tt
  

  If they fail, you can check, whether your FS is mounted with xattrs enabled. "mount" should list "user_xattr" as mount option for your FS.

  If it doesn’t you can try adding it in your /etc/fstab. After that it might still not work, which probably means that the kernel has been compiled with that feature disabled. Problem generating Haiku VMWare image mailing list thread.

  On some Linux distributions (Debian/Ubuntu/..., for example), you may also need to install the attr package first:

  sudo apt-get install attr
  

• This mailing list reply seems to have better information.
  You can check the xattr support on your partition with

      mount | grep devicename
  

  where "devicename" is the device of the partition you want to check. For example, on a Gentoo box checking hda2 you may get:

      /dev/hda2 on /home type ext3 (rw,noatime,user_xattr)
  

  and you can see xattr support is enabled here.

  If you need to enable xattr on your partition you just need to remount it with:

      sudo mount -o remount -o user_xattr devicename
  

  and if you want to enable xattr at the next boot edit /etc/fstab at the line of devicename. It would look something like this:

  /dev/hda2       /home   ext3    noatime,user_xattr      0 3
  

• What does the build system do when native extended attributes aren't used?

  Under BeOS incompatible platforms that cannot make use of xattr, the build system is restricted to the generic attribute emulation (using separate files). This is likely slower and also requires you to clean up the $(HAIKU_OUTPUT_DIR)/generated/attributes directory from time to time. If you're only doing full builds that doesn't matter at all, since you would delete the generated/{attributes,objects,tmp} directories before a build anyway. build/mirror/torrent host mailing list thread.

• From Ticket #2772, Attribute mixups are known to happen when building without even xattr-ref and when not building from the scratch (i.e. after deleting generated/objects and generated/attributes).