All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Welsh Duggan <mwd@cert.org>
To: dsterba@suse.cz
Cc: Wang Shilong <wangsl.fnst@cn.fujitsu.com>,
	linux-btrfs@vger.kernel.org, miaox@cn.fujitsu.com
Subject: Re: [PATCH] Btrfs-progs: receive: fix the case that we can not find subvolume
Date: Tue, 17 Dec 2013 10:40:41 -0500	[thread overview]
Message-ID: <tntbo0fcwp2.fsf@watermonitor.yellow.cert.org> (raw)
In-Reply-To: <20131217150919.GP6498@twin.jikos.cz> (David Sterba's message of "Tue, 17 Dec 2013 16:09:19 +0100")

David Sterba <dsterba@suse.cz> writes:

> On Tue, Dec 17, 2013 at 05:13:49PM +0800, Wang Shilong wrote:
>> If we change our default subvolume, btrfs receive will fail to find
>> subvolume. To fix this problem, i have two ideas.
>> 
>> 1.make btrfs snapshot ioctl support passing source subvolume's objectid
>
>> 2.when we want to using interval subvolume path, we mount it other place
>> that use subvolume 5 as its default subvolume.
>
> 3. Tell the user to mount the toplevel subvol by himself and run receive
>    again

Ugh.  I hope that would be considered a short-term hack waiting for a
better solution, perhaps requiring a kernel upgrade.  From a user's
perspective there is no reason this should be necessary, and requiring
this would be extraordinarily surprising.  "Why is btrfs unable to find
my snapshot?  It's right there!"  Moreover, this used to work just fine
in previous versions of btrfs-progs.

>> We'd better use the second approach because it won't bother kernel change.
>
> I don't think that the silent mount is the right way to fix it, that way
> the btrfs tool tooks responsibility not to break anything.  Like the
> unhandled umount failure below. I think admins and power users do not
> like to see some random tool mess with the system like this.
>
>> @@ -199,6 +200,10 @@ static int process_snapshot(const char *path,
>> const u8 *uuid, u64 ctransid,
>>  	char uuid_str[BTRFS_UUID_UNPARSED_SIZE];
>>  	struct btrfs_ioctl_vol_args_v2 args_v2;
>>  	struct subvol_info *parent_subvol = NULL;
>> +	char *dev = NULL;
>> +	char tmp_name[15] = "btrfs-XXXXXX";
>> +	char tmp_dir[30] = "/tmp";
>
> Mounting valuable data under /tmp is dangerous, what if some /tmp
> cleaner starts to remove old files. I've seen that happen in practice.

Agreed.  If you _were_ to continue to implement it like this, you should
include code to respect the TMPDIR envvar at the very least.

-- 
Michael Welsh Duggan
(mwd@cert.org)

  parent reply	other threads:[~2013-12-17 15:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-17  9:13 [PATCH] Btrfs-progs: receive: fix the case that we can not find subvolume Wang Shilong
2013-12-17 15:09 ` David Sterba
2013-12-17 15:27   ` Wang Shilong
2013-12-17 15:40   ` Michael Welsh Duggan [this message]
2013-12-18  2:55     ` Miao Xie
2013-12-18  3:29       ` Michael Welsh Duggan
2013-12-18  3:54         ` Wang Shilong
2013-12-18  4:06           ` Michael Welsh Duggan
2013-12-18  5:03             ` Wang Shilong
2013-12-18 20:57               ` Michael Welsh Duggan
2013-12-20  2:33                 ` Michael Welsh Duggan
2013-12-19 16:48     ` 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=tntbo0fcwp2.fsf@watermonitor.yellow.cert.org \
    --to=mwd@cert.org \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=miaox@cn.fujitsu.com \
    --cc=wangsl.fnst@cn.fujitsu.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 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.