Skip to contentSkip to conversation

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

DISCUSSION Juergen Sauer 2 participants 2 messages Jan 26, 2015 Btrfs file system

lore
Share & tools
lore
#0 lore raw

-----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, [email protected]
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-----

#1 lore raw

Juergen Sauer posted on Mon, 26 Jan 2015 13:16:33 +0100 as excerpted:

Quoted 5 lines

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...

Signature · 3 lines
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