From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: dsterba@suse.cz, Greed Rong <greedrong@gmail.com>,
linux-btrfs@vger.kernel.org
Subject: Re: BTRFS: Transaction aborted (error -24)
Date: Fri, 12 Jun 2020 13:38:03 +0800 [thread overview]
Message-ID: <434d03cf-01ba-3051-8dcb-22fd70de9957@gmx.com> (raw)
In-Reply-To: <20200611135244.GP27795@twin.jikos.cz>
[-- Attachment #1.1: Type: text/plain, Size: 2882 bytes --]
On 2020/6/11 下午9:52, David Sterba wrote:
> On Thu, Jun 11, 2020 at 08:37:11PM +0800, Qu Wenruo wrote:
>>
>>
>> On 2020/6/11 下午7:20, David Sterba wrote:
>>> On Thu, Jun 11, 2020 at 06:29:34PM +0800, Greed Rong wrote:
>>>> Hi,
>>>> I have got this error several times. Are there any suggestions to avoid this?
>>>>
>>>> # dmesg
>>>> [7142286.563596] ------------[ cut here ]------------
>>>> [7142286.564499] BTRFS: Transaction aborted (error -24)
>>>
>>> EMFILE 24 /* Too many open files */
>>>
>>> you can increase the open file limit but it's strange that this happens,
>>> first time I see this.
>>
>> Not something from btrfs code, thus it must come from the VFS/MM code.
>
> Yeah, this is VFS. Creating a new root will need a new inode and dentry
> and the limits are applied.
>
>> The offending abort transaction is from btrfs_read_fs_root_no_name(),
>> which is updated to btrfs_get_fs_root() in upstream kernel.
>> Overall, it's not much different between the upstream and the 5.0.10 kernel.
>>
>> But with latest btrfs_get_fs_root(), after a quick glance, there isn't
>> any obvious location to introduce the EMFILE error.
>>
>> Any extra info about the worload to trigger the bug?
>
> I think it's from get_anon_bdev, that's called from btrfs_init_fs_root
> (in btrfs_get_fs_root):
>
> 1073 int get_anon_bdev(dev_t *p)
> 1074 {
> 1075 int dev;
> 1076
> 1077 /*
> 1078 * Many userspace utilities consider an FSID of 0 invalid.
> 1079 * Always return at least 1 from get_anon_bdev.
> 1080 */
> 1081 dev = ida_alloc_range(&unnamed_dev_ida, 1, (1 << MINORBITS) - 1,
> 1082 GFP_ATOMIC);
> 1083 if (dev == -ENOSPC)
> 1084 dev = -EMFILE;
> 1085 if (dev < 0)
> 1086 return dev;
> 1087
> 1088 *p = MKDEV(0, dev);
> 1089 return 0;
> 1090 }
> 1091 EXPORT_SYMBOL(get_anon_bdev);
>
> And comment says "Return: 0 on success, -EMFILE if there are no
> anonymous bdevs left ".
>
> The fs tree roots are created later than the actual command is executed,
> so all the errors are also delayed. For that reason I moved eg. the root
> item and path allocation to the first phase. We could do the same for
> the anonymous bdev.
The first question is, do we really need per-root anonymous bdev?
IMHO btrfs can shared the same anonymous bdev across the same fs, no
need for each root to own one.
The user-visible change would be, statefs() will alwasy return the same
bdev for all roots.
User would lose the ability to distinguish different roots from the same
fs, but I doubt if that would really impact the use cases.
Thanks,
Qu
>
> The problem won't go away tough, the question is why is the IDA range
> unnamed_dev_ida exhausted.
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2020-06-12 5:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-11 10:29 BTRFS: Transaction aborted (error -24) Greed Rong
2020-06-11 11:20 ` David Sterba
2020-06-11 12:37 ` Qu Wenruo
2020-06-11 13:52 ` David Sterba
2020-06-12 3:15 ` Greed Rong
2020-06-12 6:41 ` Qu Wenruo
2020-06-12 17:13 ` David Sterba
2020-06-15 12:50 ` Greed Rong
2020-06-16 0:38 ` Qu Wenruo
2020-06-18 12:34 ` David Sterba
2020-06-19 4:04 ` Greed Rong
2020-06-19 4:41 ` Qu Wenruo
2020-06-12 5:38 ` Qu Wenruo [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=434d03cf-01ba-3051-8dcb-22fd70de9957@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=dsterba@suse.cz \
--cc=greedrong@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).