From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Bug Report Data Rescue: btrfs send ... btrfs set prop on linux 3.18-2 on Arch Linux
Date: Mon, 26 Jan 2015 13:38:09 +0000 (UTC) [thread overview]
Message-ID: <pan$d4a72$2fba9dd8$b6d20a1e$30871850@cox.net> (raw)
In-Reply-To: 54C63021.8000502@automatix.de
Juergen Sauer posted on Mon, 26 Jan 2015 13:16:33 +0100 as excerpted:
> I think this is an Bug in btrfs send, not to check if an btrfs
> filesystem is mounted ro for refusing working.
>
> It may be much more easier to recover damaged systems, if such annoying
> thngs would not occour.
That has been noted before, and is indeed considered a bug.
The problem is that in normal circumstances, a read-only mount wasn't
considered secure enough, because the user could make it writable while
the send was underway, causing the send to fail.
But at minimum, there needs to be a way to do a send from a forced-read-
only filesystem, you are correct, thus the bug.
I don't know whether they plan to relax the requirement and live with the
chance of a user making it writable (admin responsibility, admin breaks
the send, admin gets to keep the pieces), or if they plan to add an
attribute to force-read-only so it can be distinguished from user-mounted-
read-only, in which case forced-read-only could be considered sufficient
for a send.
But indeed, the current situation is acknowledged to be "less than ideal"
by the devs, which will probably do something about it at some point,
based on comments. I don't know how soon that "some point" might be,
however...
--
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
prev parent reply other threads:[~2015-01-26 13:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-26 12:16 Bug Report Data Rescue: btrfs send ... btrfs set prop on linux 3.18-2 on Arch Linux Juergen Sauer
2015-01-26 13:38 ` Duncan [this message]
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$d4a72$2fba9dd8$b6d20a1e$30871850@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;
as well as URLs for NNTP newsgroup(s).