Zygobasically 'rm -rf subvol; btrfs sub del subvol' to free all the non-open files. the subvol stays on disk until a few days later when the last FD closes on it
Knorriebut does it still block the cleaner that long?
ZygoI don't always have control over when FDS get released
Zygoand it only takes one to hold the entire subvol
CyberShadowA subvolume root became unreadable with a "bad tree block start" error. Any way to recover the subvolume's contents?
CyberShadowIs there no way to scan for blocks that look like directory records or something like that?
CyberShadowbtrfs-recover skips over the subvolume in question with any options I tried.
CyberShadowbtrfs-restore*
argnotwhat is the effect of using btrfs replace with a 4tb src and 8tb target?
argnotwill 8tb be available
argnoti have 4tb and 8tb hdd in raid1, trying to replace the 4tb with an 8tb disk
multicoreargnot: works ok, do a btrfs resize after the replace
argnotrighto!
argnotthanks
Kelsarthere are kernel cmdline options you can use
Kelsarrcu_nocbs=0-15
Kelsarofc need to adjust how many cores you got
Kelsarand a sufficient new enough kernel
Kelsarwhups, sorry for the noise
jkilpatrI have a raid 1 btrfs array to which I just added a new device and rebalanced, I used the balance cancel command after a few days because I needed to reboot my machine. Unmounted cleanly all that jazz
jkilpatrnow mount tells me wrong fs type, bad superblock, bad option
jkilpatrcheck shows no issues, restore works fine, as far as I can tell there's no issue with the array at all, it just won't mount
jkilpatrah there's somthing in dmesg super_total_bytes mismatch with fs_devices total_rw_byes
jkilpatrfailed to reach chunk tree
jkilpatrAnyways I'm restoring the important stuff I can tinker with getting it to mount afte
jkilpatrafter*
multicorejkilpatr: you have unaligned partitions
multicore(most likely)
multicoreif the difference is small
multicorejkilpatr: IIRC 4.14 kernel got some fixes on the issue but i'm not sure if those will help in your situation, but there's a 'rescue fix-device-size' in the latest btrfs-progs
multicorejkilpatr: if the difference between those two values is larger than "some" kilobytes it's a different issue
jkilpatrmulticore, hmm think I could do some gparted magic to align with existing data still there?
multicorejkilpatr: not sure that it helps at this point... maybe someone other knows?
multicorejkilpatr: it's pretty easy to have last sector unaligned
multicore4k-aligned that is...
multicorejkilpatr: you're on 4.13 kernel ?
jkilpatrmulticore, yes fedora
multicorejkilpatr: it's possible that the fs is mountable with 4.12 kernel
jkilpatrmulticore, if it where mountable would I just stick with 4.12 until a fix came out or could I do some repair once mounted?
multicorejkilpatr: there's a fix already
multicorejkilpatr: btrfs rescue ...
jkilpatrmulticore, not finding that in my tools version or on the manpage online
multicorejkilpatr: or boot to 4.12 and fix it manually
jkilpatrit's fix-device-size?
multicorejkilpatr: yes
multicorejkilpatr: or boot to 4.12 and fix it manually
jkilpatrwhat would a manual fix look like? a scrub?
multicorejkilpatr: well you'd need to 4k-align your partitions
multicorejkilpatr: if the start of partition isn't 4k-aligned the you're in trouble anyway
multicorejkilpatr: but most likely it's the last sector that's unaligned (with recent tools)
jkilpatrmulticore, I'll give it a go thanks
multicorejkilpatr: you can't grow the partition the larger, you'll ned the shrink it slightly
multicorejkilpatr: in that case you'll have to shrink the affected device first fith btrfs fi resize
multicorejkilpatr: if so, make it smaller than needed then shrink the partition and then btrfs resize to mac
multicorejkilpatr: max
multicorejkilpatr: but using fix-device-size should be easier
multicorejkilpatr: get it from git
jkilpatrmulticore, will do
jkilpatrmulticore, going to wait for my restore to finish and get semi-important data off first. Obviously anything critical has multiple non-btrfs backups, but i would be kinda sad to lose some of this.
jkilpatrso better safe than story.
multicorejkilpatr: mounting with 4.12 (or maybe 4.14?) would be better than btrfs rescueing the files
multicorejkilpatr: restoring, sorry
multicorejkilpatr: the issue with restore is that you don't know if you'll get corrupted data from it...
Kobazso there's corruption issues with 4.13 ?
darklingNo, it's just that restore doesn't verify checksums.
jkilpatrah thanks for the warning.