From: Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk>
To: "Lukáš Czerner" <lczerner@redhat.com>
Cc: Prashant Shah <pshah.mumbai@gmail.com>, linux-ext4@vger.kernel.org
Subject: Re: Maximum number of directories
Date: Tue, 05 Feb 2013 14:30:24 +0000 [thread overview]
Message-ID: <2743619.5F0TAJAmZW@deuteros> (raw)
In-Reply-To: <alpine.LFD.2.00.1302051309320.3225@localhost>
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 <tvrtko.ursulin@onelan.co.uk>
> > To: Prashant Shah <pshah.mumbai@gmail.com>
> > Cc: linux-ext4@vger.kernel.org
> > 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
> > >
> > > <tvrtko.ursulin@onelan.co.uk> 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
--
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:[~2013-02-05 14:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-04 10:55 Maximum number of directories Tvrtko Ursulin
2013-02-04 13:19 ` Prashant Shah
2013-02-04 13:36 ` Tvrtko Ursulin
2013-02-04 15:58 ` Prashant Shah
2013-02-05 13:06 ` Lukáš Czerner
2013-02-05 14:30 ` Tvrtko Ursulin [this message]
2013-02-05 14:43 ` Lukáš Czerner
2013-02-05 14:58 ` Tvrtko Ursulin
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=2743619.5F0TAJAmZW@deuteros \
--to=tvrtko.ursulin@onelan.co.uk \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=pshah.mumbai@gmail.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 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.