Re: Subject: [PATCH 12/16] Squashfs: header files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux