From: Andreas Dilger <adilger@turbolinux.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Andreas Dilger <adilger@turbolinux.com>,
torvalds@transmeta.com,
Linux kernel development list <linux-kernel@vger.kernel.org>,
Ext2 development mailing list <ext2-devel@lists.sourceforge.net>
Subject: Re: [PATCH] ext2 cleanups
Date: Thu, 12 Jul 2001 16:29:39 -0600 (MDT) [thread overview]
Message-ID: <200107122229.f6CMTdji028251@webber.adilger.int> (raw)
In-Reply-To: <E15Kl6L-0006Zk-00@the-village.bc.nu> "from Alan Cox at Jul 12, 2001 07:22:13 pm"
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
prev parent reply other threads:[~2001-07-12 22:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-11 22:29 Andreas Dilger
2001-07-11 22:55 ` Alexander Viro
2001-07-12 18:22 ` Alan Cox
2001-07-12 22:29 ` Andreas Dilger [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200107122229.f6CMTdji028251@webber.adilger.int \
--to=adilger@turbolinux.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=ext2-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®