From: Anand Jain <anand.jain@oracle.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>, Qu Wenruo <wqu@suse.com>,
linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 3/3] btrfs-progs: fix the stray fd close in open_ctree_fs_info()
Date: Thu, 8 Feb 2024 08:23:18 +0530 [thread overview]
Message-ID: <0b10c270-b08e-41f4-9673-449226e3f218@oracle.com> (raw)
In-Reply-To: <31d07ebd-0147-4761-85fb-5d07e67a6b0e@gmx.com>
On 2/8/24 02:35, Qu Wenruo wrote:
>
>
> On 2024/2/8 03:06, Anand Jain wrote:
>>
>>> index c053319200cb..05323b2cd393 100644
>>> --- a/kernel-shared/disk-io.c
>>> +++ b/kernel-shared/disk-io.c
>>> @@ -913,6 +913,7 @@ struct btrfs_fs_info *btrfs_new_fs_info(int
>>> writable, u64 sb_bytenr)
>>> fs_info->metadata_alloc_profile = (u64)-1;
>>> fs_info->system_alloc_profile = fs_info->metadata_alloc_profile;
>>> fs_info->nr_global_roots = 1;
>>> + fs_info->initial_fd = -1;
>>> return fs_info;
>>> @@ -1690,7 +1691,10 @@ struct btrfs_fs_info *open_ctree_fs_info(struct
>>> open_ctree_args *oca)
>>> return NULL;
>>> }
>>
>>
>>> info = __open_ctree_fd(fp, oca);
>>> - close(fp);
>>> + if (info)
>>
>>
>>> + info->initial_fd = fp;
>>
>> Why not do this in __open_ctree_fd()?
>
> Because we want to keep open()/close() in the same layer when possible.
>
>> then in the parent function, __open_ctree_fd you could:
>>
>> if (!info)
>> close(fp);
>>
>>
>>> + else
>>> + close(fp);
>>
>>> return info;
>>> }
>>> @@ -2297,6 +2301,8 @@ skip_commit:
>>> btrfs_release_all_roots(fs_info);
>>> ret = btrfs_close_devices(fs_info->fs_devices);
>>> + if (fs_info->initial_fd >= 0)
>>> + close(fs_info->initial_fd);
>>> btrfs_cleanup_all_caches(fs_info);
>>> btrfs_free_fs_info(fs_info);
>>> if (!err)
>>
>>
>> Essentially this patch converts the following nested open close
>>
>>
>> fd1 open
>> fd1 write zero
>> fd1 write temp-sb
>> fd2 open
>> fd2 read super
>> fd3 open devices
>> fd2 close
>> fd1 write temp-sb-to-remaining-dev-if-any
>> fd3 write good-sb
>> fd3 close
>> fd1 close
>>
>> to
>>
>> [1]
>> fd1 open
>> fd1 write zero
>> fd1 write temp-sb
>> fd2 open
>> fd2 read super
>> fd3 open devices
>> fd1 write temp-sb-to-remaining-dev-if-any
>> fd3 write good-sb
>> fd3 close
>> fd2 close
>> fd1 close
>>
>>
>> However the patch
>> [PATCH RFC] btrfs-progs: mkfs: optimize file descriptor usage in
>> mkfs.btrfs
>>
>>
>> achieved: (And reduced one less fd)
>>
>> fd1 open
>> fd1 write zero
>> fd1 write temp-sb
>> fd1 read super
>> fd2 open devices
>> fd1 write temp-sb-to-remaining-dev-if-any
>> fd2 write good-sb
>> fd2 close
>> fd1 close
>
> The problem we are hitting don't care how many fds we opened or
> whatever, as long as the final close is later than the final fs commit.
Indeed, reusing fewer fd is a good cleanup.
>
>>
>>
>> This patch saves the temporary fd (which is a helper fd to read the sb.
>> fd2 in [1]) into a new member fs_info::initial_fd, does not make much
>> sense to me. This fix is a kind of a quick, patchy solution rather
>> than a ground-up clean design, imo.
>
> Nope, your version needs all caller of open_ctree_fs_info() to converted
> to the new interface.
It is a step in the right direction.
> This one keeps the interface untouched and still solves the problem.
>
> Yes, this can be enhanced, but not in the way you did.
>
> The proper way is to make open_ctree_fs_info() to not to rely on any
> external fd, but really make open_ctree_fs_info() to only open fds for
> its devices.
It depends on when the parent's fd is closed. Sequential
is better imo (See Josef comments in my patch), keeping
only one fd open at any time.
David's concerns about excess udev events and calls to
btrfs dev scan should be fine for mkfs since
no good-sb written yet.
> This would make open_ctree_fs_info() to get rid of __open_ctree_fd()
> completely.
It's a step forward, but adding another member to fs_info
for a helper fd as in this patch isn't wise.
> That would be a large work and does not provide really much benefit > compared to the current workaround.
Improving open_ctree are more in line with my patch's goal.
Thanks, Anand
>
> Thanks,
> Qu
>
>>
>> Thx. Anand
>>
>>
next prev parent reply other threads:[~2024-02-08 2:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-02 0:59 [PATCH 0/3] btrfs-progs: hunt down the stray fd close causing race with udev scan Qu Wenruo
2024-02-02 0:59 ` [PATCH 1/3] btrfs-progs: rescue: properly close the fs for clear-ino-cache Qu Wenruo
2024-02-02 8:48 ` Anand Jain
2024-02-02 0:59 ` [PATCH 2/3] btrfs-progs: tune: fix the missing close() Qu Wenruo
2024-02-02 9:01 ` Anand Jain
2024-02-02 0:59 ` [PATCH 3/3] btrfs-progs: fix the stray fd close in open_ctree_fs_info() Qu Wenruo
2024-02-07 16:36 ` Anand Jain
2024-02-07 21:05 ` Qu Wenruo
2024-02-08 2:53 ` Anand Jain [this message]
2024-02-07 9:52 ` [PATCH 0/3] btrfs-progs: hunt down the stray fd close causing race with udev scan David Sterba
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=0b10c270-b08e-41f4-9673-449226e3f218@oracle.com \
--to=anand.jain@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=wqu@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox