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 ...
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 ...
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 ...
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 ...
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 ...
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
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 ...
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 ...
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.
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 ...
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 mounted.
So, it ...
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 ...
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 ...
# 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 ...
It seems like you are referring to @badroot using the wrong path.
If I am reading your shell prompt correctly, your current directory is ~, your home directory — which is probably /home/mlissner or similar. You are specifying the path to the subvolume as a relative path (does not start with /), so you are effectively asking to delete ...
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 ...
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 ...
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 ...
If nice caused lots of I/O, you would want to do:
ionice -c 3 nice ...
so that the impact of the I/O would be minimized.
Conversely, if ionice performed lots of computation, you would want to do
nice -n 19 ionice ...
to minimize its CPU impact.
But neither of these is true, they're both very simple commands (they just make a system call to change a ...
Kernel 5.1 added ZSTD level support. I tested it with rc1 today using a mount option compress=zstd:12 in /etc/fstab. The default level is 3. To be clear: The change affects only files that are written after this mount command. Some benchmark results: https://lkml.org/lkml/2019/1/28/1930
loop isn't a partition table - you haven't got one of those on a whole disk filesystem. Whatever you are using that's showing you loop may be doing this because it can't find a partition table. Apparently parted on a LVM setup does this.
If these drives are not the ones you use to boot then there is no issue with installing a filesystem on the whole drive ...
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 ...
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 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 ...
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 ...