On Wed, Apr 15, 2015 at 09:14:17AM -0600, Andreas Dilger wrote:
> Nak. ostr.len is the variable being swabbed, and it is a __u32.
No, Dan is right; sd->len has been changed to be 16 bits on disk, per
Andreas' suggestion, and I missed changing the cpu_to_le32() to be
cpu_to_le16() here. The fact that the in-memory representation
happens to be 32-bits doesn't matter, it's the fact that on-disk
representation is 16-bits which is important here.
In practice the filename length can never be larger
i_sb->s_blocksize(), so we could probably change struct ext4_str to
use an __u16 --- but at least at one point RISC architectues can
sometimes handle 32-bit values more efficiently than 16-bit values,
and it's probably not worth the effort to make the change.
- Ted
--
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
