Bug Report Data Rescue: btrfs send ... btrfs set prop on linux 3.18-2 on Arch Linux

Bug Report Data Rescue: btrfs send ... btrfs set prop on linux 3.18-2 on Arch Linux

[Juergen Sauer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moin,

this weekend a ssd disk got an problem.

No Problem, I thought... but real word acts sometime other the you think :)

1. Szenario
I got an media Error on a ssd disk. So, I think trimming the whole
device may work.
Mounting the btrfs in rw is not possible anymore. Because the system is
going to write on damaged blocks.

Mounting ro is possible.
So I tried to
	mount -o ro,subvol=/ /dev/sdl1 /mnt -> worked.

The Try to send the ro-mounted subvol "rootfs", which I want to recover
did not work:
	btrfs send -f /srv/backup/rootfs.btrfs rootfs
	ERROR: /mnt/rootfs is not read-only

The try to change the ro-flag
	btrfs prop set rootfs ro true
	ERROR: failed to set flags for rootfs. Read-only file system

was impossible.

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.

mit freundlichen Grüßen
Jürgen Sauer
- -- 
Jürgen Sauer - automatiX GmbH,
+49-4209-4699, juergen.sauer@automatix.de
Geschäftsführer: Jürgen Sauer,
Gerichtstand: Amtsgericht Walsrode • HRB 120986
Ust-Id: DE191468481 • St.Nr.: 36/211/08000
GPG Public Key zur Signaturprüfung:
http://www.automatix.de/juergen_sauer_publickey.gpg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlTGMCEACgkQW7UKI9EqarG8QwCgu80ihnBxKrnjy4rzzbrz6Riu
wS0AoIEiNicS/6Zz12ct7T4fZncW5xsP
=3PPi
-----END PGP SIGNATURE-----

Re: Bug Report Data Rescue: btrfs send ... btrfs set prop on linux 3.18-2 on Arch Linux

[Duncan]

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