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
next prev parent 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