public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox