Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Questions about extended file attributes (xattrs) #917

Open
pjotrek-b opened this issue Nov 4, 2024 · 2 comments
Open

Questions about extended file attributes (xattrs) #917

pjotrek-b opened this issue Nov 4, 2024 · 2 comments
Labels
docs Changes in documentation or help text

Comments

@pjotrek-b
Copy link

Hello everyone 😄

It's about btrfs-documentation:
I'd like to ask about technical details on extended attributes (xattrs) on btrfs, and found these pages:

Which both don't really list or mention extended file attributes handling (xattrs).
I know btrfs can do xattrs, and ArchWiki mentions possible size-constraints, but I'm interested in the specific limits and settings for xattrs on btrfs 😄

I'm moving this as issue as question here, following advice from @kdave in btrfs/linux#1455

If anyone wants to talk about this or point me towards some code/docs, I'd be very grateful! 🍰

@adam900710
Copy link
Collaborator

XATTRS is stored with key (<inode number> XATTR_ITEM 0), its related data is btrfs_file_extent_item but only in the inline extent mode.

And xattrs are stored as inline data extents, meaning it's limited by two things:

  • Sector size
    Inline data extent can not reach sector size. For most filesystems it's 4K.
    This is just a soft limit, but will make kernel implementation much easier.

  • Inline data extent size
    This is limited by node size (metadata size), since we're storing everything inside metadata.
    This is a hard limit, but shouldn't cause any hassle because we're using 16KiB as node size for a long long time.

@pjotrek-b
Copy link
Author

@adam900710 : This is great information, thank you!

Do I understand this correctly:

  1. 4k sector size:
    Every xattr byte (all keys + all values) must stay below 4k?
    "Soft limit" means: Theoretically adjustable - but not really tested or really laid out for?

  2. "16kiB as node size"
    I don't yet fully understand this.
    Do you mean: Internally btrfs could handle up-to-16kiB xattrs - if the sector size would be that big?

So if I'd like to use xattrs like BeFS or HFS/APFS where even binary-data (eg images) are stored: would btrfs' defaults be capped to 4k in total right now?

Thank you so much! 😄

@kdave kdave added the docs Changes in documentation or help text label Nov 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Changes in documentation or help text
Projects
None yet
Development

No branches or pull requests

3 participants