i_dir_acl related cleanup

I am wondering whether we can use i_size_high without looking at file mode (why restrict only to regular files ? )

-aneesh

From: Aneesh Kumar K.V <[email protected]>
Date: Tue, 16 Oct 2007 12:25:18 +0530
Subject: [PATCH] ext4: code cleanup

rename ext4_inode.i_dir_acl to i_size_high
drop ext4_inode_info.i_dir_acl as it is not used

---

fs/ext4/ialloc.c          |    1 -
fs/ext4/inode.c           |   12 ++++--------
include/linux/ext4_fs.h   |    5 ++---
include/linux/ext4_fs_i.h |    1 -
4 files changed, 6 insertions(+), 13 deletions(-)

index 922c64d..f8d41b1 100644
@@ -711,7 +711,6 @@ got:

	if (!S_ISDIR(mode))
		ei->i_flags &= ~EXT4_DIRSYNC_FL;
	ei->i_file_acl = 0;
-	ei->i_dir_acl = 0;
	ei->i_dtime = 0;
	ei->i_block_alloc_info = NULL;
	ei->i_block_group = group;

index f5f64ff..1da3477 100644
@@ -2735,7 +2735,7 @@ void ext4_read_inode(struct inode * inode)

		inode->i_gid |= le16_to_cpu(raw_inode->i_gid_high) << 16;
	}
	inode->i_nlink = le16_to_cpu(raw_inode->i_links_count);

- inode->i_size = le32_to_cpu(raw_inode->i_size);
+ inode->i_size = le32_to_cpu(raw_inode->i_size_lo);

	ei->i_state = 0;
	ei->i_dir_start_lookup = 0;
@@ -2764,9 +2764,7 @@ void ext4_read_inode(struct inode * inode)
	    cpu_to_le32(EXT4_OS_HURD))
		ei->i_file_acl |=
			((__u64)le16_to_cpu(raw_inode->i_file_acl_high)) << 32;
-	if (!S_ISREG(inode->i_mode)) {
-		ei->i_dir_acl = le32_to_cpu(raw_inode->i_dir_acl);
-	} else {
+	if (S_ISREG(inode->i_mode)) {
		inode->i_size |=
			((__u64)le32_to_cpu(raw_inode->i_size_high)) << 32;
	}
@@ -2900,7 +2898,7 @@ static int ext4_do_update_inode(handle_t *handle,
		raw_inode->i_gid_high = 0;
	}
	raw_inode->i_links_count = cpu_to_le16(inode->i_nlink);

- raw_inode->i_size = cpu_to_le32(ei->i_disksize);
+ raw_inode->i_size_lo = cpu_to_le32(ei->i_disksize);

	EXT4_INODE_SET_XTIME(i_ctime, inode, raw_inode);
	EXT4_INODE_SET_XTIME(i_mtime, inode, raw_inode);
@@ -2915,9 +2913,7 @@ static int ext4_do_update_inode(handle_t *handle,
		raw_inode->i_file_acl_high =
			cpu_to_le16(ei->i_file_acl >> 32);
	raw_inode->i_file_acl_lo = cpu_to_le32(ei->i_file_acl);
-	if (!S_ISREG(inode->i_mode)) {
-		raw_inode->i_dir_acl = cpu_to_le32(ei->i_dir_acl);
-	} else {
+	if (S_ISREG(inode->i_mode)) {
		raw_inode->i_size_high =
			cpu_to_le32(ei->i_disksize >> 32);
		if (ei->i_disksize > 0x7fffffffULL) {

index d7f15a4..bacafd9 100644
@@ -303,7 +303,7 @@ struct ext4_mount_options {

struct ext4_inode {
	__le16	i_mode;		/* File mode */
	__le16	i_uid;		/* Low 16 bits of Owner Uid */
-	__le32	i_size;		/* Size in bytes */
+	__le32	i_size_lo;	/* Size in bytes */
	__le32	i_atime;	/* Access time */
	__le32	i_ctime;	/* Inode Change time */
	__le32	i_mtime;	/* Modification time */
@@ -326,7 +326,7 @@ struct ext4_inode {
	__le32	i_block[EXT4_N_BLOCKS];/* Pointers to blocks */
	__le32	i_generation;	/* File version (for NFS) */
	__le32	i_file_acl_lo;	/* File ACL */
-	__le32	i_dir_acl;	/* Directory ACL */
+	__le32	i_size_high;
	__le32	i_obso_faddr;	/* Obsoleted fragment address */
	union {
		struct {
@@ -359,7 +359,6 @@ struct ext4_inode {
	__le32	i_version_hi;	/* high 32 bits for 64-bit version */
};

-#define i_size_high i_dir_acl

#define EXT4_EPOCH_BITS 2
#define EXT4_EPOCH_MASK ((1 << EXT4_EPOCH_BITS) - 1)

index 94baea0..16249b9 100644
@@ -85,7 +85,6 @@ struct ext4_inode_info {

	__le32	i_data[15];	/* unconverted */
	__u32	i_flags;
	ext4_fsblk_t	i_file_acl;
-	__u32	i_dir_acl;
	__u32	i_dtime;

	/*

1.5.3.4.206.g58ba4-dirty

Well, traditionally this was restricted to S_IFREG files, but to be honest I've thought recently that directories should also be able to pass 2GB in size (which we've hit in our testing, at "only" 25M files/dir or so, depending on the length of the filenames). So, my opinion is that we should start allowing this, and fix up e2fsprogs in the same way.

There are other things that need to be fixed in order to allow larger directories (number of levels in htree is currently limited to 2 by the code, even though the format is more flexible, and the logical htree block number is currently limited to 2^24 blocks = 64GB for 4kB blocksize). The extra 8 bits of the logical block number were reserved for "leaf fullness" data so that it was also possible to merge nearly empty adjacent directory leaf blocks efficiently, but that was never implemented.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.