BTRFS unmountable after resizing with GParted

Today I resized my BTRFS partition to it’s minimum size in GParted and now it’s not mountable anymore.
I have not done anything that could be destructive in any way while trying to recover the partition myself.

These are the error messages I get when trying to mount:

[ 4226.491943] BTRFS info (device nvme0n1p1): disk space caching is enabled
[ 4226.491956] BTRFS info (device nvme0n1p1): has skinny extents
[ 4226.494842] BTRFS error (device nvme0n1p1): device total_bytes should be at most 142432272384 but found 480102055936
[ 4226.494862] BTRFS error (device nvme0n1p1): failed to read chunk tree: -22
[ 4226.499822] BTRFS error (device nvme0n1p1): open_ctree failed

btrfs recover/restore aren’t doing anything.

My theory is that I could just resize the partition to match the original size, leaving the filesystem alone. What do you guys think?
Next time I will just use btrfs fielsystem resize for sure…

Resizing just the partition did the trick.
I have all of my files back!

1 Like

Just FYI shrinking a partition is like a neighbour putting a fence on your property - all your stuff is suddenly gone! Gparted is often “helpful” and calls the filesystem shrinker for you, but it sounds like in this case it didn’t do that. IMO you should never shrink a partition since many filesystems may lose performance / optimal layout when shrunk. Instead copy data, wipe, and format. (If you must shrink, manually use the filesystem shrinker, measure size, and shrink partition to match with some fudge factor).

Good to hear. I’d recommend making a backup and reformating your partition again with mkfs.btrfs. There is a chance that you have data loss from when you shrunk it. Luckily BTRFS has checksums, so if a file is incorrect it will log it in journalctl or syslog.

2 Likes

Did you run btrfs filesystem resize before running gparted? (I’ve never done that, nor heard of anyone doing so.)

No I haven’t because with other filesystems gparted shrinks the filesystem before shrinking the partition.

I didn’t have any dataloss at all!

The reason I had to do it this way is that I needed a backup of the many small files and fast. My backup destination was also a smaller SSD than the one I had to back up and the only way to get it done quick enough was by shrinking the partition and cloning it sequentially.
What shot me in the foot is that gparted indeed doesn’t seem to shrink btrfs partitions, or at least that time it didn’t. I think it’s a bug because gparted claims to support shrinking and growing btrfs partitions since version 0.10.0

When I restore the backup I’ll of course temporarily mount the image and copy the files over.

I’m curious, why not send a snapshot? Was that not fast enough in your case?

If you ever need to backup lots of small files fast, I’d suggest using tar with fast compression (like lzo). Part of the slowness of copying many small files is writing all the metadata and the per-file operation of the copying. With tar you’re just writing a large stream of continuous bytes.

Same applies for copying over the network. Piping tar into “ssh host tar -xv” is surprisingly effective