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
