Hello Ted,
I'm working on the patches for large xattrs support again based on the
previous patch made by Kalpak Shah. There are some small issues in the
previous patch, I'd fix them and rebase the patch on the latest ext4 codes.
Per the thread of
http://kerneltrap.org/mailarchive/linux-ext4/2009/2/9/4931244, there are
two features need to be implemented:
1) store large xattr value (with value_size > blocksize) in an external
xattr inode
2) increase xattr space by allocating a single chunk of up to 64kB (in
size) contiguous xattr blocks
The first one has been implemented in the previous patch, and I'm
working on the second one, which would handle "medium-sized" xattrs more
efficiently.
Now, I've the same question as that in the above thread:
In xattr.{h,c}, all of the macros and functions assume the xattr space
is contiguous with entries growing downwards and values growing upwards
(aligned to the end of the space). Especially, the create, replace,
remove and shift operations of xattrs are all performed inside a
contiguous buffer. This is no problem with in-inode xattr space and
single external xattr block which is associated with one block buffer.
But for multiple xattr blocks, since the data of them would be read into
different block buffers, which are not contiguous, most of the existing
macros and functions need to be changed. Is this way acceptable?
In order to make most of the codes remain as-is, we could allocate a
contiguous large buffer (up to 64kB in size) to handle all of the data.
However, we have to memcpy the data from block buffers to the large
buffer, and after the data are changed, we need memcpy the data back to
block buffers to make the data written into the block device. Is this
way reasonable?
Could you please give me some suggestions on how to solve this issue?
Thanks!
--
Best regards,
Yu Jian
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
