Sandy McArthur Jr posted on Wed, 04 Feb 2015 12:31:07 -0500 as excerpted: > Does a btrfs scrub verify the integrity of the whole filesystem or just > the data in that filesystem?
Btrfs scrub verifies both data and metadata /checksum/ integrity. From the below it looks like that's very likely what you're most worried about anyway and you likely already get what I explain in the next paragraph, but for the benefit of others that read this... =:^) A lot of people misunderstand what scrub does and try to use it as if it were btrfs check, verifying metadata structure and function integrity as well, and then wonder why their filesystem passes scrub and yet won't balance or has other filesystem errors. Thus the emphasis on /checksum/. (Meta)data can be valid as saved and still be corrupt, because it was corrupted before the save due to a bug. The checksum, and thus scrub, verifies that you're getting exactly what was saved, but it, by itself, doesn't say anything about whether what was saved was actually valid in the first place, and a lot of folks miss the significance of that difference until it is explained to them. > I recently removed some unreliable drives from my multi-volume RAID1 > btrfs filesystem and ran a scrub that completed with two corrected > errors (see below). I've struggled with this filesystem due to poor > choices in hardware on my part and had to recover it several times. As > of now I've eliminated all older drives or drives labeled as "desktop" > drives. (Knowing what I know now, I'm impressed with how well btrfs has > preserved my data despite myself.) > > I'm at a point where I can grow my existing btrfs filesystem as RAID1 or > I can afford to migrate data to a new btrfs single filesystem and then > add drives back in to get back to RAID1 mirroring again. Is there value > to starting a fresh btrfs filesystem given my history? > > > # btrfs scrub status /mcmedia/ ; echo ; btrfs --version > scrub status for 94b3345e-2589-423c-a228-d569bf94ab58 > scrub resumed at Mon Feb 2 22:03:14 2015 and finished after 204126 > seconds > total bytes scrubbed: 23.38TiB with 2 errors > error details: csum=2 > corrected errors: 2, uncorrectable errors: 0, unverified errors: 0 > > Btrfs v3.18.2 If you like you can run a btrfs check (--readonly, without --repair or similar write option) and/or btrfs balance, and if they complete without error, it's reasonably safe to assume your filesystem is "clean". That said, personally, I prefer to start "clean" every few kernel (and thus btrfs-tools userspace as well) cycles in any case, for a couple reasons. Here, I do it as part of my regular backup cycle, where my first-level backup is a set of btrfs of the same size, and I do a fresh mkfs.btrfs to purge the old backup, mount the new filesystem, copy everything over from the working filesystem, reboot to the backup (for root) or unmount the working btrfs and mount the backup to test the backup, then when I'm satisfied with the now tested backup, reverse the cycle, doing a mkfs.btrfs of my normal working filesystem and copying everything back from the backup. (FWIW, my second level backup is non-btrfs, reiserfs in my case since I've used it for years and it has proved itself very resilient since data=ordered by default, thru the various hardware issues I've had. I do test pre-release kernels and that way, if there's a serious btrfs bug that eats both my working copy and the backup when I try to boot to it for recovery, I still have the reiserfs backup, which will hopefully be unaffected.) The reasons: 1) Btrfs is still under rapid, not entirely stable yet, development. By starting clean I eliminate the filesystem back-history and with it the possibility of some previously unknown side effect of some long fixed bug coming back to haunt me. This probably isn't as likely to eliminate issues now as it was back before say 3.11 (when they started dropping the most dire warnings, IIRC), but I'm used to doing it now, and call it sysadmin superstition if you like, but I still rest better when I can say, OK, I know for sure that filesystem couldn't have been affected by anything previous to 3.x kernel and userspace, as that's when I created it. 2) As long as you don't have to worry about compatibility with old kernels, a fresh mkfs.btrfs allows you to take advantage of (relatively) newer filesystem options like skinny-metadata, no-holes, and 16 KiB nodesizes. These make the filesystem more efficient. While some such features can be enabled at runtime, not all of them can, and the old data/ metadata will still be written with the old options until a balance or whatever to rewrite them. Of course if you need to maintain compatibility with old enough kernels you'll want to turn off these features anyway, and this reason disappears. Meanwhile, if the filesystem is still reasonably new, time-wise, even if it has been thru some tough hardware issues, and you originally created it with the options you wanted already, this reason goes away in that case as well, as the available options have remained steady for awhile now, tho the defaults have recently changed for a couple of them. Bottomline: While you're likely fine in terms of filesystem stability, particularly if you run a btrfs check and a balance and they both work fine, I'd still personally recommend a fresh mkfs for the reasons above, given the current opportunity and the fact that running the check and balance are likely to take a good chunk of the time that starting with a fresh mkfs.btrfs, copying things over, and balancing back to the expanded raid1, would take, and you won't know if the existing setup is reliable until you do that check and balance anyway, so you may well end up with a clean filesystem in any case. IOW, if it were my system, I'd go the clean mkfs.btrfs route. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
