Marc MERLIN posted on Wed, 09 Apr 2014 09:51:34 -0700 as excerpted: > But since we're talking about this, is btrfsck ever supposed to return > clean on a clean filesystem?
FWIW, it seems to return clean here, on everything I've tried it on. But I run relatively small partitions (the biggest is I believe 40 gig, my media partitions are still reiserfs on spinning rust, while all my btrfs partitions are on SSD and most are raid1 both data/metadata, with the exceptions (my normal /boot and the backup /boot on the other ssd in the pair that's btrfs raid1 for most partitions) being tiny mixed-data/ metadata dup), and keep them pretty clean, running balance and scrub when needed. I had seen some scrub recoveries back when I was doing suspend-to-ram and the system wasn't reliably resuming, I've quit doing that and recently did a new mkfs.btrfs and restored from backup on the affected filesystems in ordered to take advantage of newer features like 16k metadata nodes, so in fact have never personally seen an unclean output of any type from btrfs check. Tho I don't run btrfs check regularly as in normal mode it's read-only anyway, and I know it can make some problems worse instead of fixing them in repair mode, so my normal idea is why run it and see stuff that might make me worried if I can't really do much about it, and I prefer balance and scrub instead if there's problems. But I have run it a few times as I was curious just what it /would/ output, and everything came up clean on the filesystems I ran it on. -- 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
