Hi all,
What is the maximum number of directories ext4 can hold in a tree layout with
a depth of ~160 and each directory node having then a couple to couple dozen
subdirectories?
I was creating such a (crazy?) tree and hit -ENOSPC at ~31 million directories
created in total with df showing only 40% use:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/data 477277612K 177766152K 275621952K 40% /data
Some lines from tune2fs made me think it should hold more, but obviously I was
mistaken? Or it is a bug?
Inode count: 29868032
Free inodes: 29848131
Regards,
Tvrtko
Hi,
On Mon, Feb 4, 2013 at 4:25 PM, Tvrtko Ursulin
<[email protected]> wrote:
> I was creating such a (crazy?) tree and hit -ENOSPC at ~31 million directories
> created in total with df showing only 40% use:
> Inode count: 29868032
> Free inodes: 29848131
Since, each directory will use a inode entry, there is some mismatch
with ~31 million directories and 19901 inodes in use. The inode usage
count should be much larger. You have max 29 million inodes available
- so max can be 29 million directories.
Try $blk
Regards.
On Monday 04 February 2013 18:49:54 Prashant Shah wrote:
> Hi,
>
> On Mon, Feb 4, 2013 at 4:25 PM, Tvrtko Ursulin
>
> <[email protected]> wrote:
> > I was creating such a (crazy?) tree and hit -ENOSPC at ~31 million
> > directories created in total with df showing only 40% use:
> >
> > Inode count: 29868032
> > Free inodes: 29848131
>
> Since, each directory will use a inode entry, there is some mismatch
> with ~31 million directories and 19901 inodes in use. The inode usage
> count should be much larger. You have max 29 million inodes available
> - so max can be 29 million directories.
Yeah, I totally forgot about the inode situation on ext filesystems. So is
tune2fs giving wrong stats for live (mounted) filesystems?
> Try $blk
What is that?
Thanks,
Tvrtko
Hi,
On Mon, Feb 4, 2013 at 7:06 PM, Tvrtko Ursulin
<[email protected]> wrote:
>> Try $blk
>
> What is that?
Typo :)
Regards.
On Mon, 4 Feb 2013, Tvrtko Ursulin wrote:
> Date: Mon, 04 Feb 2013 13:36:29 +0000
> From: Tvrtko Ursulin <[email protected]>
> To: Prashant Shah <[email protected]>
> Cc: [email protected]
> Subject: Re: Maximum number of directories
>
> On Monday 04 February 2013 18:49:54 Prashant Shah wrote:
> > Hi,
> >
> > On Mon, Feb 4, 2013 at 4:25 PM, Tvrtko Ursulin
> >
> > <[email protected]> wrote:
> > > I was creating such a (crazy?) tree and hit -ENOSPC at ~31 million
> > > directories created in total with df showing only 40% use:
> > >
> > > Inode count: 29868032
> > > Free inodes: 29848131
> >
> > Since, each directory will use a inode entry, there is some mismatch
> > with ~31 million directories and 19901 inodes in use. The inode usage
> > count should be much larger. You have max 29 million inodes available
> > - so max can be 29 million directories.
>
> Yeah, I totally forgot about the inode situation on ext filesystems. So is
> tune2fs giving wrong stats for live (mounted) filesystems?
Not sure what situation you're referring to. Directory as any other
file is represented by an inode and there is a limited number of
inodes in the file system.
Using tune2fs on live/mounted file system is bad idea and the
information might not be correct (exactly for this reason it is
_NOT_ recommended to run fsck on live file system). Use 'df -i' if
you want to get information about inode count.
And to answer your previous question, yes the number of directory
entries is limited. The number depends on the size of the directory
entries (the name of the file) and the size of the file system
block. From my calculation on 4k file system it can hold 3870945
files with 255B long filenames in the single directory in the ideal
case, please correct me if I am wrong.
Unfortunately the problem might appear as the directory hash tree
gets more fragmented which will limit the number of directory
entries it can hold - this can be fixed with e2fsck -D.
Thanks!
-Lukas
Hi,
On Tuesday 05 February 2013 14:06:14 Lukáš Czerner wrote:
> On Mon, 4 Feb 2013, Tvrtko Ursulin wrote:
> > Date: Mon, 04 Feb 2013 13:36:29 +0000
> > From: Tvrtko Ursulin <[email protected]>
> > To: Prashant Shah <[email protected]>
> > Cc: [email protected]
> > Subject: Re: Maximum number of directories
> >
> > On Monday 04 February 2013 18:49:54 Prashant Shah wrote:
> > > Hi,
> > >
> > > On Mon, Feb 4, 2013 at 4:25 PM, Tvrtko Ursulin
> > >
> > > <[email protected]> wrote:
> > > > I was creating such a (crazy?) tree and hit -ENOSPC at ~31 million
> > > > directories created in total with df showing only 40% use:
> > > >
> > > > Inode count: 29868032
> > > > Free inodes: 29848131
> > >
> > > Since, each directory will use a inode entry, there is some mismatch
> > > with ~31 million directories and 19901 inodes in use. The inode usage
> > > count should be much larger. You have max 29 million inodes available
> > > - so max can be 29 million directories.
> >
> > Yeah, I totally forgot about the inode situation on ext filesystems. So is
> > tune2fs giving wrong stats for live (mounted) filesystems?
>
> Not sure what situation you're referring to. Directory as any other
> file is represented by an inode and there is a limited number of
> inodes in the file system.
The situation that inode blocks are statically allocated at mkfs time.
> Using tune2fs on live/mounted file system is bad idea and the
> information might not be correct (exactly for this reason it is
> _NOT_ recommended to run fsck on live file system). Use 'df -i' if
> you want to get information about inode count.
Yes, later I figured out that tune2fs -l does not give current stats for live
filesystems. I did not expect that to be dangerous though. And I also forgot
about 'df -i'. Thing is, I did not hit this limit since the previous century
so guess I subconsciously assumed inode limits are an outdated concept. :)
Regards,
Tvrtko
On Tue, 5 Feb 2013, Tvrtko Ursulin wrote:
> Date: Tue, 05 Feb 2013 14:30:24 +0000
> From: Tvrtko Ursulin <[email protected]>
> To: Lukáš Czerner <[email protected]>
> Cc: Prashant Shah <[email protected]>, [email protected]
> Subject: Re: Maximum number of directories
>
>
> Hi,
>
> On Tuesday 05 February 2013 14:06:14 Lukáš Czerner wrote:
> > On Mon, 4 Feb 2013, Tvrtko Ursulin wrote:
> > > Date: Mon, 04 Feb 2013 13:36:29 +0000
> > > From: Tvrtko Ursulin <[email protected]>
> > > To: Prashant Shah <[email protected]>
> > > Cc: [email protected]
> > > Subject: Re: Maximum number of directories
> > >
> > > On Monday 04 February 2013 18:49:54 Prashant Shah wrote:
> > > > Hi,
> > > >
> > > > On Mon, Feb 4, 2013 at 4:25 PM, Tvrtko Ursulin
> > > >
> > > > <[email protected]> wrote:
> > > > > I was creating such a (crazy?) tree and hit -ENOSPC at ~31 million
> > > > > directories created in total with df showing only 40% use:
> > > > >
> > > > > Inode count: 29868032
> > > > > Free inodes: 29848131
> > > >
> > > > Since, each directory will use a inode entry, there is some mismatch
> > > > with ~31 million directories and 19901 inodes in use. The inode usage
> > > > count should be much larger. You have max 29 million inodes available
> > > > - so max can be 29 million directories.
> > >
> > > Yeah, I totally forgot about the inode situation on ext filesystems. So is
> > > tune2fs giving wrong stats for live (mounted) filesystems?
> >
> > Not sure what situation you're referring to. Directory as any other
> > file is represented by an inode and there is a limited number of
> > inodes in the file system.
>
> The situation that inode blocks are statically allocated at mkfs time.
Yes, that is true.
>
> > Using tune2fs on live/mounted file system is bad idea and the
> > information might not be correct (exactly for this reason it is
> > _NOT_ recommended to run fsck on live file system). Use 'df -i' if
> > you want to get information about inode count.
>
> Yes, later I figured out that tune2fs -l does not give current stats for live
> filesystems. I did not expect that to be dangerous though. And I also forgot
> about 'df -i'. Thing is, I did not hit this limit since the previous century
> so guess I subconsciously assumed inode limits are an outdated concept. :)
Running tune2fs -l on live file system is not dangerous, I did not
said that. Running fsck on live file system on the other hand _is_
dangerous.
-Lukas
>
> Regards,
>
> Tvrtko
>
>
On Tuesday 05 February 2013 15:43:51 Lukáš Czerner wrote:
> > > > Yeah, I totally forgot about the inode situation on ext filesystems.
> > > > So is
> > > > tune2fs giving wrong stats for live (mounted) filesystems?
> > >
> > > Not sure what situation you're referring to. Directory as any other
> > > file is represented by an inode and there is a limited number of
> > > inodes in the file system.
> >
> > The situation that inode blocks are statically allocated at mkfs time.
>
> Yes, that is true.
Indeed it is. :)
> > > Using tune2fs on live/mounted file system is bad idea and the
> > > information might not be correct (exactly for this reason it is
> > > _NOT_ recommended to run fsck on live file system). Use 'df -i' if
> > > you want to get information about inode count.
> >
> > Yes, later I figured out that tune2fs -l does not give current stats for
> > live filesystems. I did not expect that to be dangerous though. And I
> > also forgot about 'df -i'. Thing is, I did not hit this limit since the
> > previous century so guess I subconsciously assumed inode limits are an
> > outdated concept. :)
> Running tune2fs -l on live file system is not dangerous, I did not
> said that. Running fsck on live file system on the other hand _is_
> dangerous.
:) Neither have I said I was running fsck or anything other than 'tune2fs -l'.
Regards,
Tvrtko