G. Michael Carter posted on Sun, 26 Jan 2014 10:11:08 -0500 as excerpted: > I've basically got four questions: > > 1. How do I repair, or drop block 35435896033280? > > 2. How do I identify which drive out of 5 this block is on? > > 3. How do I detect which drive is causing the errno=-5 IO failure > > 4. How do I identify what files I'm going to loose by this block > problem? As a simple btrfs user myself (not a dev, tho hopefully they'll get you a better answer later), I can't answer most of these. But #4... btrfs scrub will normally report (in dmesg, not in the command output) what file is associated with a checksum failure if it can't fix it from a second copy if available. That does assume that the failure is in a data block, not metadata, but since metadata defaults to raid1 mode (if multi-device, dup mode if single device) anyway, you'll likely have a second copy to fix from, in that case, unless of course you configured single or raid0 metadata, in which case you're likely but predictably screwed as you're deliberately configuring less reliability when you chose those modes for metadata, and I'd suggest mkfs and restore from backup. With the file information, you can delete the file, and hopefully when the block is rewritten at some point in the future, the drive will automatically mark it bad and rotate in one of its spares. -- 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
