On Oct 2, 2013, at 10:53 AM, Charles Cazabon <charlesc-lists-bt...@pyropus.ca> wrote:
>> 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. I know but it's a 16TB array, do you really want to start over from scratch? No. And neither do most people. So this isn't a use case that's probably getting a ton of testing. >> 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. OK except there is corruption. We just don't know for sure if it's just files or if it's the file system. If you don't know already what caused it, it's not really correct to say what doesn't result in corruption. Also the write-intent bitmap isn't configured by default, and you didn't previous say that it was. Is this an internal or external bitmap? >> 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). If only hardware worked exactly per spec, and also didn't lie about committing data to disk rather than merely keeping it in cache, this may be true. But hardware lies, it has bugs. And the kernel isn't bug free either. Chris Murphy-- 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
