All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: dsterba@suse.cz, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 0/5] Convert seed devices to proper list API
Date: Thu, 23 Jul 2020 11:02:14 +0300	[thread overview]
Message-ID: <dc2379cf-9e8f-031e-4214-d68f6e4d41b1@suse.com> (raw)
In-Reply-To: <20200722142607.GX3703@twin.jikos.cz>



On 22.07.20 г. 17:26 ч., David Sterba wrote:
> On Wed, Jul 15, 2020 at 01:48:45PM +0300, Nikolay Borisov wrote:
>> This series converts the existing seed devices pointer in btrfs_fs_devices to
>> proper list api. First 4 patches are cleanups preparing the code for the switch.
> 
>> Patch 5 has more information about the required transformations, it might seem
>> lengthy but he logic everywhere is pretty much the same so shouldn't be that
>> cumbersome to review.
> 
> The first 3 patches are clear, I start to have doubts in 4 and 5 was a
> stop for me, but I'm not saying it's wrong. Just that I always thought
> the seed devices + the sprout are close to a tree structure but you're
> switching that to a linear list.
> 
> I'll add the first three patches now, but would appreciate some help
> with 4 and 5.
> 

Ok, let's take it one at a time, patch 4:

Originally fs_info for fs_devices is set by btrfs_set_fs_info_ptr called
by btrfs_sysfs_add_mounted. THe latter is called in open_ctree before
block_groups are read i.e on before the fs is exposed. My patch instead
changes this so that fs_info is set in btrfs_init_devices_late, called
from btrfs_read_roots, called by init_tree_roots. The last function is
called before btrfs_sysfs_add_mounted. This means as far as setting
fs_devices is concerned its fs_info is being set earlier. And this is
correct.

Now, let's think about clearing it, the old code cleared it in :

btrfs_sysfs_remove_mounted which is called from:

1. fail_sysfs label in open_ctree
2. close_ctree
3. failure in btrfs_sysfs_add_mounted which does goto fail_fsdev_sysfs

So how are those 3 situation handled by the new code :

1 and 3 - the last function called in open_ctree is btrfs_close_devices
in case of errors and both failure labels are before it, so we are
guaranteed that on failure in open_ctree fs_devices will have it's
fs_info being NULL.

2. Again, last function called in close_ctree is btrfs_close_devices so
we are guaranteed on unmount fs_devices will have fs_info being NULL.

Thus the patch doesn't introduce any functional changes but IMO makes
the code more coherent.


Regarding patch 5 - I don't know what made you think there is a
tree-like structure involved. Simply looking at the old way seeds are
iterated:

	while (seed_devices) {
		fs_devices = seed_devices;
		seed_devices = fs_devices->seed;
 		close_fs_devices(fs_devices);
 		free_fs_devices(fs_devices);
 	}


There's no conditional deciding if we should go left/right of the tree.
Or let's take for example deleting from a list of seed devices:

		tmp_fs_devices = fs_info->fs_devices;
		while (tmp_fs_devices) {
			if (tmp_fs_devices->seed == fs_devices) {
				tmp_fs_devices->seed = fs_devices->seed;
				break;
			}
			tmp_fs_devices = tmp_fs_devices->seed;
		}

Here a simple linear search is performed and when a member of the seed
list matches our fs_devices it simply pointed 1 past our fs_devices

When the if inside the loop matches we get the following situation:

[tmp_fs_devices]->[fs_devices]->[fs_devices->seeds]

Then we perform [tmp_fs_devices] -> [fs_devices->seed]

So a simple deletion, just the fact you were confused shows the old code
is rather wonky.



  reply	other threads:[~2020-07-23  8:02 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-15 10:48 [PATCH 0/5] Convert seed devices to proper list API Nikolay Borisov
2020-07-15 10:48 ` [PATCH 1/5] btrfs: Factor out reada loop in __reada_start_machine Nikolay Borisov
2020-08-18 15:02   ` Josef Bacik
2020-08-29 15:06   ` Anand Jain
2020-08-31 12:24     ` David Sterba
2020-07-15 10:48 ` [PATCH 2/5] btrfs: Factor out loop logic from btrfs_free_extra_devids Nikolay Borisov
2020-07-15 12:32   ` kernel test robot
2020-07-15 12:32     ` kernel test robot
2020-07-15 12:39     ` Nikolay Borisov
2020-07-15 17:39   ` kernel test robot
2020-07-16  7:17   ` [PATCH v2] " Nikolay Borisov
2020-08-29 15:13     ` Anand Jain
2020-08-18 15:03   ` [PATCH 2/5] " Josef Bacik
2020-07-15 10:48 ` [PATCH 3/5] btrfs: Make close_fs_devices return void Nikolay Borisov
2020-08-18 15:05   ` Josef Bacik
2020-08-29 15:14   ` Anand Jain
2020-07-15 10:48 ` [PATCH 4/5] btrfs: Simplify setting/clearing fs_info to btrfs_fs_devices Nikolay Borisov
2020-08-18 15:08   ` Josef Bacik
2020-08-26 10:50   ` Anand Jain
2020-07-15 10:48 ` [PATCH 5/5] btrfs: Switch seed device to list api Nikolay Borisov
2020-07-15 13:14   ` kernel test robot
2020-07-15 13:14     ` kernel test robot
2020-07-15 19:11   ` kernel test robot
2020-07-16  7:25   ` [PATCH v2] " Nikolay Borisov
2020-08-18 15:19     ` Josef Bacik
2020-08-30 14:39     ` Anand Jain
2020-07-24  7:36   ` [PATCH 5/5] " Nikolay Borisov
2020-09-02 15:58   ` Anand Jain
2020-09-03  9:03     ` Nikolay Borisov
2020-09-03  9:33       ` Anand Jain
2020-09-10 16:28         ` David Sterba
2020-07-22 14:26 ` [PATCH 0/5] Convert seed devices to proper list API David Sterba
2020-07-23  8:02   ` Nikolay Borisov [this message]
2020-08-21 14:33     ` David Sterba
2020-08-17 19:19 ` Nikolay Borisov

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=dc2379cf-9e8f-031e-4214-d68f6e4d41b1@suse.com \
    --to=nborisov@suse.com \
    --cc=dsterba@suse.cz \
    --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 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.