The btrfs manpage fails to document the property subcommand, which I found by grep'ing the source. It's also in btrfs --help.
To set a snapshot to read-write, you do something like this:
btrfs property set -ts /path/to/snapshot ro false
Change that to true to set it to read-only.
You can also use list to see the available properties:
btrfs property list ...
It's not the default since for robustness reasons one may want a copy to take place to protect against data corruption. Also for performance reasons you may want the writes to happen at copy time rather than some latency sensitive process working on a CoW file and being delayed by the writes possibly to a different part of a mechanical disk. Note that from ...
It sounds like you want etckeeper from Joey Hess of Debian, which manages files under /etc using version control. It supports git, mercurial, darcs and bazaar.
git is the VCS best supported by etckeeper and the VCS users are most likely to know. It's possible that your distribution has chosen to modify etckeeper so its default VCS is not git. You should ...
Disadvantages of btrfs compared to ext4:
btrfs doesn't support badblocks
This means that if you've run out of spare non-addressable sectors that the HDD firmware keeps to cover for a limited number of failures, there is no way to mark blocks bad and avoid them at the filesystem level.
Swap files are only supported via a loopback device, which complicates ...
With the program btrfstune, which is part of more recent versions of the normal btrfs-tools, the UUID of a offline file system can be changed. If the partition is eg. /dev/sda1, use following command to generate a new, random UUID:
btrfstune -u /dev/sda1
To specify which value should be used, use an uppercase -U followed by a (valid) UUID string, for ...
The command in recent versions of snapper is (I don't remember when it was introduced, but the version in e.g., openSUSE 13.2 supports this):
snapper delete number1-number2
So to delete all snapshots (assuming you have no more than 100000 of them) you'd do:
snapper delete 1-100000
Obviously this only deletes snapshots on the default root config, so for a ...
cp --reflink=always is almost certainly working correctly. If it weren't, you would be getting an error. By design, that's the difference between --reflink=always and --reflink=auto. The error would look like this:
# Filesystem that does not support the feature at all
cp: failed to clone `xx' from `yy': Inappropriate ioctl for device
# Filesystem that does ...
The answer (as I now know): concurrency.
In short: My sequential write, either using dd or when copying a file (like... in daily use), becomes a pseudo-random write (bad) because four threads are working concurrently on writing the encrypted data to the block device after concurrent encryption (good).
Mitigation (for "older" kernels)
The negative effect ...
Don't know why it's not the default, maybe so that it behaves the same as other copying utilities (rsync, cpio, pax, tar...) which have no support for it (or when files are copied across an interface that doesn't allow that (like NFS, samba, fuse file systems layers...).
I was in the same situation a few years ago, and looking at GNU cp code quickly, it's ...
As someone who is using a btrfs filesystem with Arch Linux for almost 2 years now I can safely say that there does not seem to be a practical limit on the number of snapshots that can be easily reached. There are some caveats though. btrfs filesystem can lead to fragmentation. It is therefore advisable to use the online defragmentation feature built into ...
A major disadvantage (especially in regards to Ubuntu switching to swap files on new installations) is that butter FS (as I like to pronounce it) does not support swapping files, see FAQ - Does btrfs support swap files? | btrfs Wiki :
Does btrfs support swap files?
Currently no. Just making a file NOCOW does not help, swap file support relies on one ...
The btrfs-tools package adds an action to the initramfs to load the btrfs module. If you purge that package (sudo apt-get purge btrfs-tools), followed by an update-initramfs -ukall if the uninstallation doesn't do it already, that should go away (though I've not tested it). If it doesn't, you can always blacklist the brtfs module in /etc/modprobe.d.
There are ways to get balance to run in this situation.
sudo btrfs fi show
sudo btrfs fi df /mount/point
sudo btrfs fi balance start -dusage=10 /mount/point
If the balance command ends with "Done, had to relocate 0 out of XX chunks", then you need to increase the "dusage" percentage parameter till at least one chunk is relocated.
if the balance command ...
From the btrfs gotchas page:
Files with a lot of random writes can become heavily fragmented (10000+ extents) causing trashing on HDDs and excessive multi-second spikes of CPU load on systems with an SSD or large amount a RAM.
On servers and workstations this affects databases and virtual machine images.
The nodatacow mount option may be ...
# take a read-only snapshot:
btrfs sub snap -r fs snapshot
... do things on fs
# rolling back:
btrfs sub del fs # at which point you'll lose those things you've done
# if you want to preserve them, just rename fs instead
btrfs sub snap snapshot fs # reinstate snapshot as a read+write fs
btrfs sub del snapshot # delete the non-longer ...
On Ubuntu 18.04 you can uninstall btrfs-support with
apt purge btrfs-progs
But that probably wouldn't save you much boot time. On my system the reason was, that I don't have a swap partition but on boot it is searched for such for about 30 seconds (while displaying the btrfs-scan).
remove the swap check
Firstly, we'll create the layout we want in the default subvolume:
btrfs subvolume snapshot / /rootfs
Note that /rootfs will be our new root filesystem, so don't make any changes to the current one after this step.
Edit /rootfs/etc/fstab to make the system use the new rootfs subvolume as root filesystem. For that, you'll need to modify it ...
Well this was a learning experience for me but I eventually figured it out. I'll explain my process here so that it's easier to know how to figure this stuff out on your own (BTRFS documentation, as I'm sure you found out, is relatively incomplete for the time being).
At first I thought that creating the subvolume was an ioctl with a handler that didn't do ...
Well, that was embarrassing. BTRFS needs to be mounted to be able to resize the partition.
How do I resize a partition? (shrink/grow)
In order to demonstrate and test the back references, Btrfs devel team has added an online resizer, which can both grow and shrink the filesystem via the btrfs commands.
First, ensure that your filesystem is ...
Regarding the nodatacow option, Ohad Rodeh's paper titled BTRFS: The Linux B-tree Filesystem states:
It cancels copy-on-write for data blocks, unless there is a snapshot.
There is no problem with creating a snapshot of a subvolume mounted with nodatacow. But since cow is required to create a snapshot, when you create one on a subvolume with nodatacow it ...
There are two options:
The second is almost always preferable to the first. Using auto means it will fallback to doing a true copy if the file system doesn't support reflinking (for instance, ext4 or copying to an NFS share). With the first option, I'm pretty sure it will outright fail and stop copying.
If you are ...
Maybe this explains ( from the btrfs wiki by the way )
A subvolume in btrfs is not the same as an LVM logical volume or a ZFS subvolume. With LVM, a logical volume is a block device in its own right (which could for example contain any other filesystem or container like dm-crypt, MD RAID, etc.) - this is not the case with btrfs.
A btrfs subvolume is not a ...
Unless you specified otherwise when you formatted, the default is to store duplicate copies of the metadata blocks for improved reliability. You probably have 2gb worth of metadata that is stored twice, using 4gb. You can see more details with btrfs filesystem df.
In particular, 1.75GB is allocated for metadata, so it consumes twice that or 3.5GB of space....
I was able to delete these snapshots by first mounting the whole btrfs volume (not the @ subvolume) and then working from there:
# mount /dev/mapper/whatever /mnt -o subvol=/
# ls /mnt
So at this point, all subvolumes (including the funky apt-snapshot ones) are visible in /mnt, so we can delete them:
# btrfs subvol ...
This has turned out to be a royal PITA. First, it's important to note that btrfs now has a proper replace command, which is very much better than add new, remove failing.
First, start by partitioning the new disk and setting up dm-crypt on it. Go ahead and unlock it.
If your disk wasn't having writes time out (which takes 360s each, apparently!) you could ...
I found out the answer by asking on the mailing-list.
btrfs doesn't do RAID per-volume, but rather on a per-chunk basis. The filesystem reserves "raw" space in (p.e.) 1GB chunks. Initializing the fs with raid1 means that every time it tries to allocate a chunk, it tries to allocate a copy of this chunk on another device.
This architecture allows mixed-size ...
Secure deletion is a tough proposition on any filesystem. Unless the filesystem is very peculiar and guarantees that there aren't other copies of the file lying around, you need to clear all the free space on the device. While you are more likely to find many bits of the file on copy-on-write filesystems, even more “static” filesystems don't have this ...
The "common wisdom" of filesystem developers is that it takes some 5 years of beating to consider a filesystem stable enough for non-experimental use. BTRFS hasn't accumulated 5 years yet, so it is considered strictly for experimental use right now. If the data on the machine aren't critical, and a rigurous backup scheme is in place, go wild. Be prepared to ...