Move folder to BTRFS sub-volume

Question

I recently formatted my /home partition using BTRFS, but since it was my first touch with this FS, I didn't know about sub-volumes.

Yesterday I reinstalled my Linux Mint and selected to mount my existing home partition as /home. Now I was surprised, that my files first seemed to be lost, but then I noticed that Linux Mint created a sub-volume called @home next to my existing user home folder.

Current situation is the following disk layout: 250 GiB SSD -- 64 GiB / (BTRFS) -- 8 GiB swap -- ~170 GiB /home (BTRFS)

When I try to move my home folder into the @home sub-volume, I get the error that there isn't enough space left (?!) although there's ~50 GiB left on this partition and I want to move, and not to copy the files. I haven't any other disk right now that I could reformat to any non-NTFS format, which would be required to keep any symlinks..

Now I got the question: How to move the files from the folder into the sub-volume correctly? And why doesn't moving the files work?

Answer 1

You can attempt a COW (copy-on-write) copy with cp -a --reflink=always /home/<whatever> /home/@home/. It's a true copy as far as the Linux VFS (virtual filesystem) is concerned, but within BTRFS the files would share the same blocks/extends so no additional space is required until you modify the files.

If the copy succeeds, modify /etc/fstab to mount the subvolume instead of the whole filesystem:

/dev/sdXn    /home    btrfs    subvol=@home

Then, reboot. If all is well, you can remove the original files:

mount /dev/sdXn /mnt
pushd /mnt
rm -fR <whatever>
popd
umount /mnt

Of course, you should have backups before attempting any of this.

Next

Once everything is good, please read the BTRFS wiki, in particular all the articles under the Guides and Usage Information. BTRFS is pretty neat and all, but it doesn't work like your traditional Linux filesystems (extN, ReiserFS, etc.). It's not one of those things one can jump into and just figure out as you go. To use BTRFS well, you gotta know what you're doing. And reading the documentation is the best way to do that.

I happen to love BTRFS, and I hope you enjoy it as well.

Answer 2

In case someone else also tries to use mv to move data between sub-volumes, which according to https://unix.stackexchange.com/a/152639/81744 sounds like it should work / be fast (reflinks should be the default mode for mv since coreutils 8.24): My practical test with coreutils-8.29 on linux-4.14.15-arch shows that copies are being created instead of file system internal links (df shows the file system size increasing, which appears odd for mv, especially with reflinks).

Thus https://unix.stackexchange.com/a/377734/81744 continues to be the correct answer, even with newer versions of coreutils, which should default to reflinks for mv.

(I would have commented on the currently best answer to add this information, but I would need 50 reputation for that, which I don't yet have.)

Answer 3

I was struck by the same issue. Splitting /home into parts for easier snapshot management turned into a weeks long nightmare. cp --reflink=always did not work for some reason (threw way too many errors at me I got lost in them).

The answer I've found at last was simple and so obvious, I'm ashamed I did not think of it before.

1. Snapshot the original subvolume.
2. Inside a snapshot, delete everything you don't need, and move the data you need to the root of the snapshot. Mostly it will be directories. It's fast and cheap.
3. Make sure ACL on the snapshot root is what you expect.
4. Mount your new subvolume where you want it.

If you've attempted to move across volumes before, but being a good system administrator, made a snapshot before that "just in case", there's a simple script to cleanup erroneous subvolume:

# cd /your/erroneous/subvolume
# find . -type f -exec cmp --silent '{}' '/your/good/snapshot/{}' \; -delete

This will remove from your erred subvolume any files that are same as those on your reserve snapshot. Do not attempt to rsync "the rest" back into snapshot. There could be partially copied files and you will lose data. Manually inspect the residue and only copy what you actually need.

---

And here's the answer to cp --reflink=always and "Invalid cross-device link" errors: this doesn't mean FS is at fault, it's just how the kernel map from extent to filename work, if you specify mounted subvolumes as targets. Mount your root FS, go into that directory and work from there with relative paths. All will be good.