6 ms·

> For data, it should be safe as long as a scrub is run immediately after any unclean shutdown Note that btrfs-scrub (according to the docs) is looking for on-

> For data, it should be safe as long as a scrub is run immediately after any unclean shutdown Note that btrfs-scrub (according to the docs) is looking for on-disk block errors, comparing the data to the CRC (or whatever algo) to see if that matches. If it can recover the original data, the bad block is re-written with the correct CRC. So btrfs-scrub does not find or fix any errors with the filesystem structure. For that you need to run btrfs-check, and that can only be done offline.

8fingerlouie 6y ago
> For that you need to run btrfs-check, and that can only be done offline. You almost never want to run btrfs-check. In itself, Btrfs is fairly "self healing", and only if you run into "weird things" in the log like invalid index files should you run check, and almost certainly never with the --repair option. The thing about Btrfs (and ZFS) is that it is Copy-on-Write, and as such, new data is written to an unused part of the filesystem. It doesn't need to modify structures of existing data, thereby reducing the risk of bad metadata. A file in Btrfs is either written or it is not. If a power outage occurs after a file has been written, but before the metadata is updated, the file is not written, and in case you're updating a file, the old file is still preserved. If a crash occurs while writing metadata, Btrfs has multiple copies of metadata, and is able to repair itself online.
chasil 6y ago
The latest mkfs.btrfs on my Oracle Linux 7 supports "crc32c, xxhash, sha256 or blake2." The relative benefits are discussed in "man 5 btrfs" in the "CHECKSUM ALGORITHM" section. man 5 btrfs | col -b | sed -n '/^CHECKSUM/,/^FILESYSTEM/p'
wtallis 6y ago
The reasoning for running a scrub after an unclean shutdown is not to catch corruption of the filesystem structure, but to catch data corruption resulting from the RAID5 write hole. If you're not using RAID5 or RAID6 for metadata, the write hole won't affect the filesystem structure and there shouldn't be any issues for btrfs-check to find.
cmurf 6y ago
This is true, although since kernel 5.2, and continuing to be enhanced, is the tree checker. There's read time and write time tree checking that can catch specific errors in the file system and prevent further confusion. This usually means it goes read-only. In the most typical case where you have a crash or power failure, you just reboot normally. No file system check happens nor is it needed. It just continues from the most recent successfully committed transaction. Since it's copy-on-write, there's no inconsistency in the file system, even if the most recent changes might be lost.

8fingerlouie 6y ago

> For that you need to run btrfs-check, and that can only be done offline. You almost never want to run btrfs-check. In itself, Btrfs is fairly "self healing", and only if you run into "weird things" in the log like invalid index files should you run check, and almost certainly never with the --repair option. The thing about Btrfs (and ZFS) is that it is Copy-on-Write, and as such, new data is written to an unused part of the filesystem. It doesn't need to modify structures of existing data, thereby reducing the risk of bad metadata. A file in Btrfs is either written or it is not. If a power outage occurs after a file has been written, but before the metadata is updated, the file is not written, and in case you're updating a file, the old file is still preserved. If a crash occurs while writing metadata, Btrfs has multiple copies of metadata, and is able to repair itself online.

chasil 6y ago

The latest mkfs.btrfs on my Oracle Linux 7 supports "crc32c, xxhash, sha256 or blake2." The relative benefits are discussed in "man 5 btrfs" in the "CHECKSUM ALGORITHM" section. man 5 btrfs | col -b | sed -n '/^CHECKSUM/,/^FILESYSTEM/p'

wtallis 6y ago

The reasoning for running a scrub after an unclean shutdown is not to catch corruption of the filesystem structure, but to catch data corruption resulting from the RAID5 write hole. If you're not using RAID5 or RAID6 for metadata, the write hole won't affect the filesystem structure and there shouldn't be any issues for btrfs-check to find.

cmurf 6y ago

This is true, although since kernel 5.2, and continuing to be enhanced, is the tree checker. There's read time and write time tree checking that can catch specific errors in the file system and prevent further confusion. This usually means it goes read-only. In the most typical case where you have a crash or power failure, you just reboot normally. No file system check happens nor is it needed. It just continues from the most recent successfully committed transaction. Since it's copy-on-write, there's no inconsistency in the file system, even if the most recent changes might be lost.