David Sterba posted on Wed, 30 Dec 2015 18:39:49 +0100 as excerpted: > On Wed, Dec 30, 2015 at 01:00:34AM +0100, Sree Harsha Totakura wrote: >> Is it possible to confine scrubbing to a subvolume instead of the whole >> file system? > > No. Srub reads the blocks from devices (without knowing which files own > them) and compares them to the stored checksums. Of course if like me you prefer not to have all your data eggs in one filesystem basket and have used partitions (or LVM) and multiple independent btrfs, in which case you scrub the filesystem you want, and don't worry about the others. =:^) It definitely helps with maintenance time -- on SSDs with all under 50 GiB partitions, scrub times per btrfs are typically under a minute, and btrfs check and balance times are similarly short. Plus, arranging to have additional partitions exactly the same size to use as backups works pretty nicely as well. =:^) OTOH, people routinely report days for multi-terabyte btrfs maintenance commands on spinning rust. =:^( Tho I do still have my media partition, along with backups, on reiserfs on spinning rust. I should think about switching that over one of these days... >> [...] Therefore, I would like to scrub the photos and documents >> subvolumes more often than the backups subvolume. Would this be >> possible with the current tools? > > The closest would be to read the files and look for any reported errors. That should work. Cat the files to /dev/null and check dmesg. For single mode it should check the only copy. For raid1/10 or dup, running two checks, ensuring one is even-PID while the other is odd-PID, should work to check both copies, since the read-scheduler assigns copy based on even/odd PID. Errors will show up in dmesg, as well as cat's STDERR. Pretty clever thinking there. =:^) -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
