From: Russell Coker <russell@coker.com.au>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>, linux-btrfs@vger.kernel.org
Subject: Re: ENOSPC with mkdir and rename
Date: Tue, 05 Aug 2014 22:17:34 +1000 [thread overview]
Message-ID: <5946755.iXasy4PIFE@xev> (raw)
In-Reply-To: <53E09B20.4020305@cn.fujitsu.com>
On Tue, 5 Aug 2014 16:51:44 Qu Wenruo wrote:
> In fact such "defeat"(or whatever) is not really btrfs only problem.
> In ext*, there is still similiar behavior: ext* has a up limit on the
> number of inode after mkfs.
> (When you mkfs.ext*, you are prompt the up limit of inodes)
> However other metadata in ext* is stored together with data, so no
> ENOSPC problem like btrfs.
There is a huge difference between BTRFS and Ext* in this regard.
The way that Ext* has always worked is that if you delete one file, pipe or
socket that isn't hard-linked, or one sym-link or directory then you free up 1
Inode. 1 free Inode allows you to create 1 file, pipe, socket, sym-link, or
directory.
Deleting a file or directory on BTRFS takes MORE metadata space (at least
temporarily) because it writes a new copy of the tree. So not only will
deleting files not immediately solve a lack of metadata space on BTRFS but it
might even make things worse.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
prev parent reply other threads:[~2014-08-05 12:17 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-02 23:35 ENOSPC with mkdir and rename Peter Waller
2014-08-03 0:28 ` Mitch Harder
2014-08-03 1:52 ` Nick Krause
2014-08-03 2:39 ` Russell Coker
2014-08-03 2:59 ` Nick Krause
2014-08-04 1:38 ` Qu Wenruo
2014-08-04 8:14 ` Peter Waller
2014-08-04 9:22 ` Clemens Eisserer
2014-08-04 9:39 ` Chris Samuel
2014-08-04 9:56 ` Clemens Eisserer
2014-08-04 10:24 ` Chris Samuel
2014-08-05 8:06 ` Duncan
2014-08-05 12:20 ` Russell Coker
2014-08-05 12:58 ` Clemens Eisserer
2014-08-05 13:02 ` Peter Waller
2014-08-10 17:21 ` Martin Steigerwald
2014-08-05 13:36 ` Chris Samuel
2014-08-06 0:04 ` Duncan
2014-08-06 0:38 ` ronnie sahlberg
2014-08-06 1:18 ` Nick Krause
2014-08-04 10:09 ` Peter Waller
2014-08-04 10:22 ` Hugo Mills
2014-08-04 10:31 ` Peter Waller
2014-08-04 10:39 ` Hugo Mills
2014-08-04 10:48 ` Peter Waller
2014-08-04 11:29 ` Hugo Mills
2014-08-04 17:09 ` Austin S Hemmelgarn
2014-08-05 8:20 ` Duncan
2014-08-05 11:31 ` Austin S Hemmelgarn
2014-08-04 11:04 ` Clemens Eisserer
2014-08-04 11:32 ` Hugo Mills
2014-08-04 13:17 ` Peter Waller
2014-08-04 13:35 ` Hugo Mills
2014-08-04 14:02 ` Austin S Hemmelgarn
2014-08-04 14:11 ` Peter Waller
2014-08-04 14:26 ` Austin S Hemmelgarn
2014-08-04 14:47 ` Russell Coker
2014-08-04 15:19 ` Mitch Harder
2014-08-04 10:50 ` Chris Samuel
2014-08-04 10:59 ` Peter Waller
2014-08-04 21:27 ` Chris Samuel
2014-08-10 17:26 ` Martin Steigerwald
2014-08-05 8:51 ` Qu Wenruo
2014-08-05 12:17 ` Russell Coker [this message]
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=5946755.iXasy4PIFE@xev \
--to=russell@coker.com.au \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo@cn.fujitsu.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.