On Thu, 28 Feb 2002, Galen Sampson wrote:

> I am curious about the file sizes of the backing files for extend
> attributes. I have compiled a custom kernel that has both extended
> attribute support and acl support.  I can sucessfully add and remove
> acls for files.  I am quite impressed.  I used a sparse backing file
> (i.e. no -p option when creating the backing file) to see if acl's would
> work.  I am aware of the security implications of this, but my only goal
> was to test them out.  The size of the backing file when used with -p
> and 388 bytes is too large of an overhead for me to live with anyhow. 
> I am curious about the file sizes displayed in 'ls -l' for these sparse
> backing files.  The sparse files are indeed small.  Unfortunately I see
> strange results with 'ls -l'.  An example... 

What's going on is that ls -l lists the size of the file in terms of
addressable space, whereas du lists the actual size in blocks.  The space
isn't actually consumed, but if you were to read at any of the addresses
in the file, you're get the zero's back associated with the sparse
locations.  With the advent of UFS2, this won't be a problem since we'll
support extended attributes natively in the file layout, and won't have to
rely on backing files.  BTW, the quota system has the same quirk: it uses
a sparse file indexed by uid or gid, leaving sparse blocks all over the
place if you have a sparse uid or gid space.  We might want to add a quirk
entry to the FAQ about this, since it will no doubt result in questions.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]      NAI Labs, Safeport Network Services

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to