On 3/11/08 4:17 PM, "Charles Manning" <
manningc2@actrix.gen.nz> wrote:
> On Tuesday 11 March 2008 14:38:27 Spencer Shimko wrote:
>> Hi,
>>
>> I've started looking into squeezing extended attribute support (xattr) into
>> YAFFS. Specifically I would be working on the generic xattr support plus
>> support for the user, trusted, and security namespaces. I've already got
>> some ideas floating around in my head but I wanted to see if anyone on list
>> has explored this before.
>
> I must first declare that I only have limited knowledge of xattr.
>
> I have done some thinking on this and a lot comes down to whether you want to
> have fully capable xattr (almost a full database system capable of megabytes
> per file) or are prepared to accept a limited xattr system that will probably
> work for most cases.
>
> The biggest question is: How big does the xattr blob **need** to be? ie
> practical size rather than theoretical.
>
> If xattr can be kept small (which I believe will serve most uses), then it is
> almost trivial to store the xattr as a blob in the object header. For
> example, if you have 2k nand pages then there's approx 1.5k of space in the
> objectheader that does nothing. Is 1.5k enough to store xattr?
>
> The next more complex (but still pretty simple) approach is more powerful.
> Currently chunkId offsets start at 1 (chunkId 0 == object header). We can
> easily start that at a bigger offset, say 1024, and use chunkIds 1..1023 to
> store xattr.
>
> I think the major issue is to try keep things simple. If the fs can just
> handle a blob (ie change one xattr means rewriting the blob) then that's a
> lot simpler than trying to make file system within a file system to handle
> xattr.
>
> The simplicity approach is fine if the xattr are smallish.
>
>
Xattrs are just name/value pairs. The name, sometimes called the xattr
prefix, actually identifies the type of xattr such as "security.", "user.",
or "trusted.". While it would be technically possible to support arbitrary
names it wouldn't be all that useful so we only provide handlers for
specific names like "security.". That means our list of names is known and
static.
Unfortunately the same is not true of values. They are arbitrary length
blobs that we would just have to blindly accept and write/read.
We would also need to support arbitrary numbers of these name/value pairs.
For example, /etc/passwd could have one xatttr in the security.* namespace
and a second xattr in the user.* namespace and so on. Current
implementations just attach a linked list of xattrs to each inode.
When you boil everything down all that is required is the ability to store a
list of name:value pairs (value being of arbitrary length) and then the
ability to associate this list with an inode. YAFFS uses Tnodes to address
this type of requirement for files right? Perhaps that is where I should be
looking.
I'm going to keep digesting the design elements involved and will come back
with some possibilities/RFC early next week but keep the suggestions coming
if anything pops into your mind in the meantime.
--Spencer
>
>>
>> I briefly thought I could get away with adding a small blob to the
>> yaffs_DeviceStruct to handle the device-level data and adding an xattr
>> object variant to handle the raw data. But now I'm not so sure since
>> xattr's aren't objects in the "object variant" sense.
>>
>> 1. Does the relationship between yaffs_Objects (parent, siblings, children)
>> preclude implementing xattrs as an object variant?
>>
>> 2. I have seen the ChunkCache but I don't think the xattr should be
>> polluting that cache. Right?
>>
>> 3. To actually get the chunk data into NAND I could use ObjectHeaders (and
>> the associated Object) or raw data. The way the "name" member of the
>> ObjectHeader struct is used in other parts of the code
>> (yaffs_FindObjectByName) leads me to believe I can't/shouldn't be using
>> them for xattr's. Correct?
>>
>> Aside from those questions, anyone aware of any work going on in this area?
>> Any show stoppers jump to mind or suggestions?
>>
>>
>> Thanks,
>> --Spencer
>>
>>
>>
>> _______________________________________________
>> yaffs mailing list
>> yaffs@lists.aleph1.co.uk
>> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
>
>
(text/plain)