David P. Quigley wrote:
Something that seems weird is the inconsistency in the ordering of these
structs. The base part is the same across all inodes but for your
reg/lreg dir/ldir pairs you seem to shuffle the order of the added
parts. Is there a reason for this? Is their layout the same on disk
(baring the extra data in the l versions)? If so they probably should be
the same in the struct.
They're deliberately shuffled about to eliminate holes (due to alignment
contraints), and to maximise compression. Shifting to cluster similar
fields can get better compression, and the current layout is the result
of a lot of work to to get the best ordering.
For example:
>> +struct squashfs_reg_inode {
>> + __le16 inode_type;
>> + __le16 mode;
>> + __le16 uid;
>> + __le16 guid;
>> + __le32 mtime;
>> + __le32 inode_number;
>> + __le32 start_block;
>> + __le32 fragment;
>> + __le32 offset;
>> + __le32 file_size;
>> + __le16 block_list[0];
>> +};
Inode_number, start_block, fragment clustered together because in most
filesystems they'll contain a lot of zero bits (filesystems mainly being
small). Better compression.
>> +
>> +struct squashfs_lreg_inode {
>> + __le16 inode_type;
>> + __le16 mode;
>> + __le16 uid;
>> + __le16 guid;
>> + __le32 mtime;
>> + __le32 inode_number;
>> + __le64 start_block;
>> + __le64 file_size;
>> + __le64 sparse;
>> + __le32 nlink;
>> + __le32 fragment;
>> + __le32 offset;
>> + __le32 xattr;
>> + __le16 block_list[0];
>> +};
Start_block, file_size have been doubled, and the fragment field
consequently moved to preserve 64-bit alignment constraints on 64-bit
quantities (no holes). Plus moving fragment means it can be grouped
with the new nlink field giving a nice run of zero bits (non-extended
regular files have an implicit nlink of 1).
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
