Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: illegal snapshot, cannot be deleted
Date: Fri, 13 Nov 2015 23:53:07 +0000 (UTC)	[thread overview]
Message-ID: <pan$b6f6$b48b3e9f$e7ad9f7$2f6462b7@cox.net> (raw)
In-Reply-To: 20151113211341.GH24333@carfax.org.uk

Hugo Mills posted on Fri, 13 Nov 2015 21:13:41 +0000 as excerpted:

> On Fri, Nov 13, 2015 at 09:11:46PM +0000, Duncan wrote:
>> Hugo Mills posted on Fri, 13 Nov 2015 19:55:20 +0000 as excerpted:
>> 
>> > receive is implemented almost exclusively in userspace, with only a
>> > couple of ioctls for mucking around with the UUIDs at the end.
>> 
>> I wasn't aware of that and had assumed kernel space.  Apart from the
>> topic of discussion here, that has implications for the old "how old is
>> too old" versioning question regarding userspace, so thanks, Hugo. =:^)
> 
> Note that send is still heavily kernel-side. It's only receive
> that's all in userspace.

Being "runtime", send's kernel-side use would be expected.

The more general rule that runtime operations are kernel side, so user 
side versioning doesn't have the same importance, unless you're trying to 
use userside tools such as check, rescue and recover, generally run on an 
unmounted btrfs, to recover from damage, since in the general case that's 
where userspace code really goes to work and thus where it's version 
becomes important.

That the receive side of the send/receive feature is an exception to this 
general rule is the news, since now we have a runtime tool, normally run 
on a mounted btrfs, where the userspace code is doing the work and 
therefore the userspace version, newer versions having the latest fixes, 
becomes important.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


  reply	other threads:[~2015-11-13 23:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-11 22:11 illegal snapshot, cannot be deleted Vedran Vucic
2015-11-12 12:32 ` Austin S Hemmelgarn
2015-11-13 16:12   ` Vedran Vucic
2015-11-13 16:30     ` Austin S Hemmelgarn
2015-11-13 17:30       ` Vedran Vucic
2015-11-13 17:55         ` Henk Slager
2015-11-13 17:57           ` Vedran Vucic
2015-11-13 18:10         ` Austin S Hemmelgarn
2015-11-13 18:42           ` Hugo Mills
2015-11-13 19:40             ` Austin S Hemmelgarn
2015-11-13 19:55               ` Hugo Mills
2015-11-13 20:20                 ` Austin S Hemmelgarn
2015-11-13 21:11                 ` Duncan
2015-11-13 21:13                   ` Hugo Mills
2015-11-13 23:53                     ` Duncan [this message]
2015-11-13 20:15             ` Vedran Vucic
2015-11-13 20:18               ` Vedran Vucic

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='pan$b6f6$b48b3e9f$e7ad9f7$2f6462b7@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --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