On Wed, Oct 10, 2018 at 9:07 PM, Larkin Lowrey <llow...@nuclearwinter.com> wrote: > On 10/10/2018 10:51 PM, Chris Murphy wrote: >> >> On Wed, Oct 10, 2018 at 8:12 PM, Larkin Lowrey >> <llow...@nuclearwinter.com> wrote: >>> >>> On 10/10/2018 7:55 PM, Hans van Kranenburg wrote: >>>> >>>> On 10/10/2018 07:44 PM, Chris Murphy wrote: >>>>> >>>>> >>>>> I'm pretty sure you have to umount, and then clear the space_cache >>>>> with 'btrfs check --clear-space-cache=v1' and then do a one time mount >>>>> with -o space_cache=v2. >>>> >>>> The --clear-space-cache=v1 is optional, but recommended, if you are >>>> someone who do not likes to keep accumulated cruft. >>>> >>>> The v2 mount (rw mount!!!) does not remove the v1 cache. If you just >>>> mount with v2, the v1 data keeps being there, doing nothing any more. >>> >>> >>> Theoretically I have the v2 space_cache enabled. After a clean umount... >>> >>> # mount -onospace_cache /backups >>> [ 391.243175] BTRFS info (device dm-3): disabling free space tree >>> [ 391.249213] BTRFS error (device dm-3): cannot disable free space tree >>> [ 391.255884] BTRFS error (device dm-3): open_ctree failed >> >> "free space tree" is the v2 space cache, and once enabled it cannot be >> disabled with nospace_cache mount option. If you want to run with >> nospace_cache you'll need to clear it. >> >> >>> # mount -ospace_cache=v1 /backups/ >>> mount: /backups: wrong fs type, bad option, bad superblock on >>> /dev/mapper/Cached-Backups, missing codepage or helper program, or other >>> error >>> [ 983.501874] BTRFS info (device dm-3): enabling disk space caching >>> [ 983.508052] BTRFS error (device dm-3): cannot disable free space tree >>> [ 983.514633] BTRFS error (device dm-3): open_ctree failed >> >> You cannot go back and forth between v1 and v2. Once v2 is enabled, >> it's always used regardless of any mount option. You'll need to use >> btrfs check to clear the v2 cache if you want to use v1 cache. >> >> >>> # btrfs check --clear-space-cache v1 /dev/Cached/Backups >>> Opening filesystem to check... >>> couldn't open RDWR because of unsupported option features (3). >>> ERROR: cannot open file system >> >> You're missing the '=' symbol for the clear option, that's why it fails. >> > > # btrfs check --clear-space-cache=v2 /dev/Cached/Backups > Opening filesystem to check... > Checking filesystem on /dev/Cached/Backups > UUID: acff5096-1128-4b24-a15e-4ba04261edc3 > Clear free space cache v2 > Segmentation fault (core dumped) > > [ 109.686188] btrfs[2429]: segfault at 68 ip 0000555ff6394b1c sp > 00007ffcc4733ab0 error 4 in btrfs[555ff637c000+ca000] > [ 109.696732] Code: ff e8 68 ed ff ff 8b 4c 24 58 4d 8b 8f c7 01 00 00 4c > 89 fe 85 c0 0f 44 44 24 40 45 31 c0 89 44 24 40 48 8b 84 24 90 00 00 00 <8b> > 40 68 49 29 87 d0 00 00 00 6a 00 55 48 8b 54 24 18 48 8b 7c 24 > > That's btrfs-progs v4.17.1 on 4.18.12-200.fc28.x86_64. > > I appreciate the help and advice from everyone who has contributed to this > thread. At this point, unless there is something for the project to gain > from tracking down this trouble, I'm just going to nuke the fs and start > over.
Is this a 68T file system? Seems excessive. For now you should be able to use the new v2 space tree. I think Qu or some dev will want to know why you're getting a crash trying to clear the v2 space cache. Maybe try clearing the v1 first, then v2? While v1 is default right now, soonish the plan is to go to v2 by default but the inability to clear is a bug worth investigation. I've just tried it on several of my file systems and it clears without error and rebuilds at next mount with v2 option. If it is the 68T file system, I don't expect a btrfs-image is going to be easy to capture or deliver: you've got 95GiB of metadata! Compressed that's still a ~30-45GiB image. -- Chris Murphy
