From: Theodore Tso <tytso@mit.edu>
To: "François Valenduc" <francois.valenduc@tvcablenet.be>
Cc: Graham Murray <graham@gmurray.org.uk>, linux-ext4@vger.kernel.org
Subject: Re: Wrong calculation of space remaining on a 32 bit system.
Date: Sun, 2 Nov 2008 18:01:35 -0500 [thread overview]
Message-ID: <20081102230135.GM8134@mit.edu> (raw)
In-Reply-To: <490E289F.4010907@tvcablenet.be>
On Sun, Nov 02, 2008 at 11:24:31PM +0100, François Valenduc wrote:
>
> How can I know if I ran out of inodes ? I already tried 128 and 256
> inode sizes but the problem occurs in both cases.
By using the command "df -i". It will list the number of inodes that
are in use.
The tuning parameters for mke2fs is -i (the inode ratio), or -N
(number of inodes). The number of inodes is normally calculated as a
ratio to the disk size. The normal inode ratio is 16384, which allows
for an average inode size of 16k. If you have a huge number of small
files, or small directories, or a huge number of symbolic links or
device nodes in the filesystem, you can run out of inodes. You can
change this either by specifying a a smaller inode ratio, or by
explicitly specifying the number of inodes you want created using the
-N option.
> As I said in my bug
> report, I found a patch dated from november 2007 which seems to adress
> the problem (see
> http://osdir.com/ml/file-systems.ext4/2007-11/msg00200.htm). Off course,
> I can't apply it any more now.
You can't apply it because it's already been applied; it's been in
mainline for quite a while.
> But it seems this kind of problem still
> exists. I have no problem to use ext4 on a 64 bit systems with logical
> volumes having approximately the same size.
That seems very strange. Maybe you have a different version of
mke2fs, or a different mke2fs.conf file? (The default inode size can
be controlled by the mke2fs.conf file.)
Can you send the output of "dumpe2fs -h" on a filesystem where you are
having this problem, and on a filesystem from the 64-bit system where
it is working correctly?
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-11-02 23:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-02 14:40 Wrong calculation of space remaining on a 32 bit system François Valenduc
2008-11-02 20:43 ` Theodore Tso
2008-11-02 21:46 ` news.gmane.org
2008-11-02 21:54 ` Graham Murray
2008-11-02 22:24 ` François Valenduc
2008-11-02 23:01 ` Theodore Tso [this message]
2008-11-03 18:28 ` François Valenduc
2008-11-03 20:24 ` Theodore Tso
2008-11-03 21:23 ` François Valenduc
2008-11-03 21:46 ` Theodore Tso
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=20081102230135.GM8134@mit.edu \
--to=tytso@mit.edu \
--cc=francois.valenduc@tvcablenet.be \
--cc=graham@gmurray.org.uk \
--cc=linux-ext4@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.