-------- Original Message --------
Subject: Re: ENOSPC with mkdir and rename
From: Peter Waller <pe...@scraperwiki.com>
To: Qu Wenruo <quwen...@cn.fujitsu.com>
Date: 2014年08月04日 16:14
Thanks for responses.
All of this is *very* surprising. I'm not new to BTRFS, I've been
using it on my own machines for multiple years. I didn't realise there
was an un-holstered footgun on my lap at this point. How can it be
made clear how to avoid the ENOSPC problem to myself and other
sysadmins? Or preferably not exist as a problem?
[snip]
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.
Btrfs only makes ENOSPC easier to happen by completly split data and
metadata, and does extra
data reserve for metadata.
If you like the ext* way, as already mentioned you can mkfs.btrfs with
-M flag.
But IMO, some tuning in btrfs chunk allocation algorithm may helps.
For example, we have a 20G disk, and 14G space is allocated to
data/metadata chunks.
Under such sitiuation, if btrfs needs new data chunk, it will allocate
up to 10% of disk, which is 2G.
But if it comes to metadata, it will only allocate up to 256M metadata
chunk.
This makes it very easy to allocate the rest of space all to data chunk.
But if btrfs can use the free space in a more diligent way when space is
not enough,
metadata and data usage should be more balanced and less ENOSPC will occur.
If nobody dislike the idea, I'd like try to implent this later.
Thanks,
Qu
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
