lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <490F42D2.8080200@tvcablenet.be>
Date:	Mon, 03 Nov 2008 19:28:34 +0100
From:	François Valenduc 
	<francois.valenduc@...ablenet.be>
To:	Theodore Tso <tytso@....edu>
CC:	Graham Murray <graham@...rray.org.uk>, linux-ext4@...r.kernel.org
Subject: Re: Wrong calculation of space remaining on a 32 bit system.

Theodore Tso a écrit :
> 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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

I indeed ran out of inode and this probably has nothing to do with 32 or
64 bit systems. The df -i output looks like this:
/dev/mapper/system-portage      45K     45K       0  100% /usr/portage

As you may have guessed, I created a logical volume for the portage tree
 of gentoo. It indeeds contains a lot of small files with all the
ebuilds. I use XFS for the portage tree on the 64 bits computer. Maybe
ext4 is not appropriate for this case. Maybe I would have the same
problem also on the 64 bits computer.

I am also attaching the dump2efs output. I finally managed to use ext4
on this computer. I created a logical volume for the /usr/src directory
and I managed to copy 2 sources of linux kernel and a clone of    the
git tree on it. The df -i output is the following:
/dev/mapper/system-src   120K     96K     25K   80% /usr/src

I checked the mke2fs.conf files on both computer and the default inode
ratio is set to 16384 on the 2 systems.

François


View attachment "dump-prob" of type "text/plain" (1738 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ