All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: dsterba@suse.cz, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RESEND v8] Add cli and ioctl to forget scanned device(s)
Date: Wed, 8 Aug 2018 07:33:08 +0800	[thread overview]
Message-ID: <aaea23f4-e76c-3301-5047-c3d3d9f097e9@oracle.com> (raw)
In-Reply-To: <20180807175138.GR3218@twin.jikos.cz>



On 08/08/2018 01:51 AM, David Sterba wrote:
> On Mon, Aug 06, 2018 at 09:09:47AM +0800, Anand Jain wrote:
>> Adds cli and ioctl to forget a scanned device or forget all stale
>> devices in the kernel.
> 
> Please provide more details about your idea of the usecase, ie. how
> excactly and when the command is supposed to be used.

  Much of this details are in the kernel change log so I didn't add
  here, wonder if you miss that?

> I vaguely recollect that we've discussed the commandline interface but
> don't remember the result. Nevertheless, I think that the 'forget'
> command should be an option of 'device scan'.

  Right. Its here[1]. As I mentioned it had typo ?

  [1]
   https://patchwork.kernel.org/patch/10092511/

>    btrfs device scan --forget /dev/sda

  This syntax is is not in line with our other cli.
  Like: btrfs device add; btrfs device delete;

> Next I'm not sure the freeing all stale devices is a good idea.

   Its not a bad idea though. You suggested it here [1] (above).

< Should
> it be more fine grained?

  The current proposed cli is also fine grained.
     btrfs device forget [device-path]
  Where it checks and releases only [device-path]

> Suppose there are several multi-device
> filesystems on the host and some of them not mounted. The devices have
> been scanned eg. via udev and the filesystems are ready to be mounted.
> Calling 'forget all' will now prevent mount without another 'device
> scan'.

   Right. So if users intention is to mount then he should not call
   btrfs device forget. (with or without any device path).

> What if a particular filesystem needs to forget the scanned devices, or
> just one filesystem:device.

  The current cli in this patch supports this..
     btrfs device forget [device-path]

  So user can forget a device.

> And there's the question how to specify the devices, it can be by device
> path or uuid or maybe device id.

  The forget part is synonym to its 'btrfs device scan [device-path]'.

  The stale devices can be of any type. As of now there is no way user
  can know their stale devices. Only way they can clean them all is
  by running
    btrfs device forget <-- without any option so cleans all unmounted
   device.

  So providing the fsid/uuid option is of no use.

Thanks, Anand

> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2018-08-08  1:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-06  1:09 [PATCH RESEND v8] Add cli and ioctl to forget scanned device(s) Anand Jain
2018-08-06  1:09 ` [PATCH] btrfs: introduce feature to forget a btrfs device Anand Jain
2018-08-06  1:09 ` [PATCH] btrfs-progs: add cli to forget one or all scanned devices Anand Jain
2018-08-07 17:51 ` [PATCH RESEND v8] Add cli and ioctl to forget scanned device(s) David Sterba
2018-08-07 23:33   ` Anand Jain [this message]
2018-08-14  2:36     ` Anand Jain

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=aaea23f4-e76c-3301-5047-c3d3d9f097e9@oracle.com \
    --to=anand.jain@oracle.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.