> On Aug 16, 2017, at 10:48 PM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: > > > >> On 8/17/17 12:42 AM, Link Dupont wrote: >>> On Thu, 2017-08-17 at 00:26 -0500, Eric Sandeen wrote: >>> Oh right, you did say RAID enclosure. >>> >>> My money is on the enclosure no longer presenting you with sectors in >>> the original order, or in an otherwise severely damaged form, for >>> whatever reason. >> >> The problem *could* be from the enclosure itself; I don't have a second one to >> test. I'm fairly sure the cause is a failing drive (I get a red LED from one of >> the two status LEDs on the front of the enclosure). >> >>> xfs_repair restores filesystem consistency but it is not a data recovery or >>> storage repair tool. ;) >> >> I get that. But since the files are there, it seemed like the file-system could >> be repaired. I'll dig up the output. > > My worry is that the "log uuid" was neither zeros nor the proper UUID; it was > something else. So it wasn't bad, unreadable sectors which got filled in with > zeros by ddrescue, it was apparently some random data coughed up by the > enclosure for some unknown reason. > > If it did that to the log, it may well have done that to many other parts > of the filesystem as well. > > -Eric > This almost makes it seem more like the enclosure controller is at fault here. I'll chase down another one. -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
