Re: Can BTRFS handle XATTRs larger than 4K?

[Robert White <rwhite@pobox.com>]

On 12/22/2014 02:55 PM, Richard Sharpe wrote:
> On Mon, Dec 22, 2014 at 2:52 PM, Robert White <rwhite@pobox.com> wrote:
>> So skipping the full ADS, what's the current demand/payoff for large XATTR space?
>
> Windows Security Descriptors (sometimes incorrectly called ACLs)
> stored by Samba.

Ah.

I know that Linux ACLs are fairly small per entry, I take it Windows' 
can be much bigger?

Having just gone off an read a lot about the many ADS possible in 
windows, they've sort of treated ever file as if it were the name of a 
phantom directory limited depth... That is you seem to be able to create 
any name as a stream name but you can't create any pathname as same.

The system-level API -- that is the complete retooling of SYS_open et al 
-- and the requsite departure from POSIX -- seems unlikely.

On the antipode, it seems like being able to put an inode reference key 
type (e.g. a name,inode pair as one of the metadata entries) could 
relieve the space constraint for a limited number of entires. The 
contents of that inode's data region would become the value of the 
single attribute.

Does that relieve Security Descriptor burden? Is each descriptor a 
separate attribute or are all the descriptors held in one attribute as a 
list-of?

Going full "phantom directory" to match Windows just seems like we get 
into the business of replacing whole kernel tidbits a la the 
inner-system effect.