Some good tips from the btrfs newsgroup for mounting removable media:
> Better yet, if your btrfs is actually on /dev/sdc right now, let’s get that fstab entry mounting it by UUID instead.
>
> ls -l /dev/disk/by-uuid | grep sdc
> lrwxrwxrwx 1 root root 10 Jan 3 09:40 12345678-9abc0-1234-5678-9a0123456789 -> ../../sdc
>
> So then:
>
> # this is not a real UUID, you need to check /dev/disk/by-uuid on your machine for a real UUID
> UUID=12345678-9abc0-1234-5678-9a0123456789 /path/to/mountpoint compress=lzo,noauto,users,user 0 0
>
> This is EXTRA important with a USB drive, since it’s HIGHLY likely it won’t always be on the same physical devicename.One other note: in this particular case, you might actually be better served setting compression by mounting the drive normally, then:
cd /path/to/drive
chattr +c . ; chattr +c * ; chattr +c .*This will set compression on by default for any future files stored on that USB drive, *without* needing any special mount options.
Why might this be a better idea? Well, if it’s a USB drive, presumably you might want to mount it on foreign systems from time to time. This way, even if you mount the drive on a foreign system that doesn’t know anything about your preferences, it will see the +c on the root directory of the drive, and store any new data on the drive compressed.
The only caveat: +c won’t set the compression algorithm to LZO. It’ll be gzip, which is the default algorithm. (And, of course, this won’t compress any EXISTING data already stored there – only NEW data written to it after you set the +c attribute.)
Rather than use a UUID, you can also set a more human readable ‘label’ for the filesystem and then mount using “LABEL=…” rather than the “UUID=…”
eg when creating a btrfs filesystem:
mkfs.btrfs -L label ...
If using multiple removable devices that will all be connected at the same time, then you must use a unique label for each of them and a corresponding line for each in /etc/fstab. If however only ever one device will ever be connected at a time, then you could use the same label for all and just use one mount command or single /etc/fstab entry.
(Or if you are running a desktop, you could simply rely on the various desktop media mount daemons 🙂 )
Yeah, I normally just let the DE handle this as that also give the file manager a prod as well. Not much use of a server right enough.
What tools are available to go back through the various versions of a file on BTRFS? I suspect there are decent enough command line ones, but for desktop use have any GUIs landed yet?
So far, the only GUI wrapper I know of is the SUSE “Snapper”:
Using Snapper to Undo System Changes
(See also: Phoronix – Why SUSE Likes The Btrfs File-System)
The Copy-On-Write feature of btrfs seems to be primarily a performance and data security feature. It also allows for very rapid snapshots and filesystem file (clone) copies to be made. At present, to rollback a file change you need to have already taken a snapshot before you made whatever changes.
I wonder if a logging mode could be added (similar to filesystem send/receive) to be able to ‘undo’ filesystem operations… That’s an idea for the btrfs list I think!
Cheers,
Martin
Snapper is installable on Ubuntu and variant (pos. Debian too I guess, with a few tweaks).
Details: https://linuxg.net/how-to-install-snapper-on-ubuntu-13-04-12-04-linux-mint-15-13-and-elementary-os-0-2-luna/