Hi Darrick,
Yes, The Alibaba uses inline data feature in our system. We are fine
with this incompatiable change, and we will handle this change by
ourselves.
Regards,
- Zheng
> On May 27, 2015, at 8:25 AM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote:
>
> Hi all,
>
> [echoing a conversation on today's concall]
>
> I'm just curious -- is there a reason why the inline data feature stores the
> data with an xattr of [EXT4_XATTR_INDEX_SYSTEM, "data"] instead of creating a
> new index value to cover "system.data"? That would allow us to set the namelen
> to zero, which fetches us an extra 4 bytes for inline data storage:
>
> struct ext4_xattr_info i = {
> .name_index = EXT4_XATTR_INDEX_SYSTEM,
> .name = EXT4_XATTR_SYSTEM_DATA,
> };
>
> becomes
>
> struct ext4_xattr_info i = {
> .name_index = EXT4_XATTR_INDEX_SYSTEM_DATA,
> .name = "",
> };
>
> The hard part, of course, is that inline.c is hardcoded to the xattr key that
> it uses (instead of using "system.data" and letting the key resolver figure it
> out), which makes it harder to switch to the optimized encoding.
>
> On the other hand, since inline data isn't in a released e2fsprogs yet, there
> still aren't very many users of it, so if we're going to make the change we
> ought to do so now while it's still fairly inexpensive to do so.
>
> The biggest problem of course is retrofitting anyone who's been using this
> feature, since old kernels require the larger encoding. So, who are those
> users, and are you willing to trade some breakage for four more bytes?
>
> It shouldn't be that hard to teach the kernel to look for either encoding of
> the xattr name. e2fsprogs uses the full string and lets the xattr code
> figure out the encoding.
>
> --D
--
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
