[PATCH] XATTR issues on JFFS2

[Kaigai Kohei]

Hello, Thanks for your comments.

David Woodhouse wrote:
> I'm happier with inventing new node types for xattrs instead of re-using
> existing nodes, I think. And I'd also like to make sure we can share
> xattr data on the medium where appropriate. In an selinux system, you'll
> end up with a _multitude_ of xattrs used for selinux, many of which will
> have precisely the same contents. Each should be stored only once on the
> flash, like hard links. The ext2 implementation manages this.

Indeed, it is key concept to separate the relationship between inode and
XATTR from XATTR-entry which contain name/value.
In my implementation, an increase/decrease of inode which shares XATTR-entry
does not need to update the XATTR-entry. It's represented by an existance of
XATTR-reference node. Therefore, it's possible to update less frequently.

If this approach is acceptable, I'm willing to implement something to do.
* Dividing the global xattr_sem semaphore into more small lock.
* Indexing the XATTR-entry by its contains, for fast looking-up shared entry.
and, Stephen suggested as follows:
* Using generic_{set|get|list}xattr method like ext2/3.

Thanks,
-- 
Linux Promotion Center, NEC
KaiGai Kohei <kaigai at ak.jp.nec.com>