On Thu, Mar 17, 2011 at 8:42 PM, Chris Mason <chris.mason@xxxxxxxxxx> wrote: > Excerpts from Jan Schmidt's message of 2011-03-17 13:37:54 -0400: >> On 03/17/2011 06:09 PM, Andrey Kuzmin wrote: >> > On Thu, Mar 17, 2011 at 5:46 PM, Jan Schmidt <list.btrfs@xxxxxxxxxxxxx >> > <mailto:list.btrfs@xxxxxxxxxxxxx>> wrote: >> > Â Â - Is it acceptable to retry reading a block immediately after the disk >> > Â Â said it won't work? Or in case of a successful read followed by a >> > Â Â checksum error? (Which is already being done right now in btrfs.) >> > >> > >> > These are two pretty different cases. When disk firmware fails read, it >> > means it has retried number of times but gave up (suggesting media >> > error), so an upper layer retry would hardly make sense. Checksum error >> > catches on-disk EDC fault, so retry is on the contrary quite reasonable. >> >> Agreed. >> >> > Â Â - Is it acceptable to always write both mirrors if one is found to be >> > Â Â bad (also consider ssds)? >> > >> > >> > Writing on read path bypassing file-system transaction mechanism doesn't >> > seem a good idea to me. Just imaging loosing power while overwriting >> > last good copy. >> >> Okay, sounds reasonable to me. Let's say we're bypassing transaction >> mechanism in the same rude manner, but only write the bad mirror. Does >> that seem reasonable? > > The bad mirror is fair game. ÂWrite away, as long as you're sure you're > excluding nodatacow and you don't allow that block to get reallocated > elsewhere. ÂYou don't actually need to bypass the transaction > mechanism, just those two things. What happens if multiple readers (allowed by read lock) attempt an overwrite? Regards, Andrey > > -chris > -- 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
