Re: Can BTRFS handle XATTRs larger than 4K?

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2531 bytes --]

On 2014-12-22 19:08, Robert White wrote:
> 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.
>

Personally, I'm thinking something more like the OS X Forks API than the 
Windows ADS API.  Forks are actually the original reason that windows 
added ADS to NTFS, and their API is much cleaner than the windows one. 
The standard there is that forks are accessible as 
'<filename>/..namedfork/<forkname>'  ..namedfork doesn't get listed by 
ls -a, but you can explicitly list '<filename>/..namedfork/' to get a 
list of forks other than the data fork.  Such an API needs almost zero 
modification to existing programs (just enough to get tar and friends to 
check if there are any named forks for each file).

The significant advantages I see to having forks are:
  1. Windows Security Descriptors
  2. Macintosh Resource Forks
  3. BeOS (and others) style associated metadata (ie, associated file 
icons/thumbnails, per-file program associations, in other words, the 
same sort of stuff that OSX uses resource forks for)
  4. Better flexibility for stuff like IMA and EVM



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]