Messages in this thread | | | From | Andreas Dilger <> | Subject | Re: [PATCH] ext2 cleanups | Date | Thu, 12 Jul 2001 16:29:39 -0600 (MDT) |
| |
Alan writes: > > This patch cleans up the ext2 code in various places. It is mostly cosmetic > > changes to comments, avoiding lines > 80 columns, removing redundant #ifdef > > lines, etc. It also adds the new COMPAT flags from the current e2fsprogs > > into include/linux/ext2_fs.h. > > Any reason for not delaying this until 2.5.0 ? (ie any bug fixes)
No, it is cosmetic only (OK, the wrong block is reported as being cleared if there is an error in ext2_free_blocks(), but that isn't much of a bug.
Neither is the 4 bytes wasted in ext2_inode_info by not_used_1, but in the -ac kernels ext2 is the largest inode struct now that NFS is out (AFAIK), so if you remove ext2 not_used_1, i_new_inode, i_osync, and put i_prealloc_count into the 16 bits freed by i_osync, along with removing i_attr_flags you can pack 10 struct inodes into a page instead of 9. Note that the current patch does not do all of that yet.
Having 10% fewer pages for inodes would save me 142*4k = 568kB of RAM on the system I'm writing this on, and frequently more as you can get a LOT of cached inodes when running updatedb or a tar or similar.
<rant> For that matter, there is a lot of cruft in struct inode that could be in a union (e.g. you can't truncate, or have quotas on a pipe, block, or char dev, and you don't need i_blocks in this case either, and you only need i_dnotify for directories (I think i_zombie also), i_flock for files, etc). That is too much for 2.4, however, and will wait for 2.5 if there is support for this. This would go along with fs-private data in slab cache so that you don't need to pay a penalty for the worst filesystem even if you don't use it. </rant>
Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |