On Mon, 9 Oct 2006, Jon Peatfield wrote:

>>  No idea though how the EAs can amount to 32k.
>
> $ cd /tmp/
> $ dd if=/dev/zero of=testing bs=100k count=500
> 500+0 records in
> 500+0 records out
> $ ls -al testing
> -rw-r--r--  1 jp107 other 51200000 Oct  9 19:21 testing
> $ du -sk testing
> 50060   testing
> $ ls -Z testing
> -rw-r--r--  jp107    other    user_u:object_r:tmp_t            testing
>
> Given how small the contexts are I thought they were squeezed into the inodes 
> (at least some google searches suggest that this is the case for ext3).

I know it is Bad Form to reply to myself but...

I'd not remembered that ext3 accounts for the block-pointer blocks as well 
as the data blocks themselves.  So given that a block-pointer-block can 
hold 1024 pointers and the inode has room for 48 pointers the space used 
by a file using N (4K) blocks is roughly (N - 48)/1024 rounded up of 
couse.  For a 50000K file that accounts for 56K (14 blocks), and the EA 
(xattr) always counts for one extra block.  Much larger files will have 
double/triple indirection blocks but those will be an even smaller extra 
proportion than this.

Is seems that setting context= on the mount options prevents the EAs being 
stored on-disk and since users will never have direct access to these fs 
(they are only visible over NFS), I've chosen to set it to 
context=user_u:object_r:file_t which does as well as anything else.

Anyway I'm now back to *thinking* I know what is going on... :-)
-- 
Jon Peatfield,  Computer Officer,  DAMTP,  University of Cambridge
Mail:  [log in to unmask]     Web:  http://www.damtp.cam.ac.uk/