On Sun, 16 Jul 2017, Christian Kujau wrote: > so, the disk enclosure attached to my RaspberryPi[0] had "some" kind of > failure last night: one of the disks appears to have some kind of hardware > problem, the other is fine, but the XFS file system cannot be mounted. > Instead of using the RPI to try the repair, I attached the enclosure to an > Intel i7 machine (16 GB RAM) and attempted to mount: After a late night chat on #xfs, it seems that the corruption may have happened due to a problem with the storage driver on this RPI and Dave commented: | and I'm pretty sure that the USB mass storage interface/driver does not | pass through cache flushes or support FUA operations. | which would explain why it appears that the inode cluster | initialisation IO isn't on disk, and it wasn't replayed by log recovery | before inode updates were recovered.... (Put here so that it can be found in the archives, in case this happens to someone else) So, that being said, the now corrupted XFS still cannot be repaired by xfs_repair (compiled from a git checkout two days ago). The full xfs_repair run can be found the in screenlog: http://nerdbynature.de/bits/4.12.0-rc7/screenlog_1.txt The xfs_logprint and xfs_metadump outputs can be provided at request. Is this something xfs_repair should be able to fix or is the filesystem just too mangled in this case? Thanks, Christian. -- BOFH excuse #431: Borg implants are failing -- 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
