Chris Murphy <li...@colorremedies.com> wrote: > On Oct 1, 2013, at 9:13 PM, Charles Cazabon wrote: > > > > Ah, I'm not looking to repair the files -- I can recopy the files easily > > enough, and rsync will pick up any files whose contents have been corrupted. > > If you run a scrub, dmesg should contain the path for affected files which > you can then delete. If it's just a checksum problem with files, the file > system doesn't need fixing.
Okay, I'll do that. > I'd wait until the raid is finished syncing. Strictly speaking, this shouldn't be necessary. mdadm arrays are fully usable from creation during the initial sync; the system tracks which bits have been initialized and which haven't. > > It's a brand new array. The initial sync is actually still going on > > (about half complete; it'll take several days to initialize an array this > > size on this hardware). > > OK maybe someone else can comment if this is expected to work, maybe on > linux-raid even. https://raid.wiki.kernel.org/index.php/Initial_Array_Creation talks about the initial (re)sync. It explicitly states: This can take quite a time and the array is not fully resilient whilst this is happening (it is however fully useable). > But now you tell us this? You didn't think it might be important to mention > that you've got a raid initially syncing, that you've formatted btrfs, > copied files over, and at some point you got a kerne lock up, and then once > restarted you ran a btrfsck? Yes. The array uses a write-intent bitmap, so the kernel lockup during the initial sync does not cause corruption; when the system is brought back up, it may re-initialize a portion that it had already initialized (i.e. it's not 100% efficient), but it doesn't result in corruption. > I would expect problems with any file system, with a system that locks up > while the raid is still syncing. No, this doesn't cause any particular problems. It's just like the normal case of a single-drive filesystem and the system crashing during a write. You just fsck to address any problems the interrupted write caused and recover the journal (if applicable). Charles -- ----------------------------------------------------------------------- Charles Cazabon GPL'ed software available at: http://pyropus.ca/software/ ----------------------------------------------------------------------- -- 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
