![]() ![]() (But if you have exhausted every other method, a few corrupted files isn't that big a deal.). This will lead to the specific file at this position to be corrupted. Then, you will zero-out this specific block.From the latest test (which will be numbered "#1" and sit at the top of the list), grab the number displayed and divide this by eight and truncating to an integer value (cf. This is the position of the first error on the disk. The last column of the test report is called LBA_of_first_error.Examine the test with either: smartctl -l selftest /dev/sda or smartctl -a /dev/sda (the latter displays everything, but the information you need is almost at the very end).You can also run a short test with smartctl -t short /dev/sda if there is a relatively recent long test (as there was in my case). Run a long self test of the drive: smartctl -t long /dev/sda.All the following operations must be ran as root (evidently). I'll repost the steps here in case the previous link becomes obsolete. The solution is based on this post Nigel Smith, the main author of XFS (if I understand correctly). Attempting to mount would lead to superblock cannot be found (or analogous) error, but no hint as to what to do next.The rest of my disk was operating flawlessly (including /, i.e.xfs_repair failed in Phase 1 with superblock read failed followed by fatal error - Input/output error.dmesg showed somewhere xfs_do_force_shutdown called around a few other xfs messages.Out of nowhere, any file in /home could not be saved/edited, etc.I'll present here the solution that worked for me, along with the reasons why the previous answer did not help. ![]() The answers above did not help me when I had this issue today (about 9.5 hours ago now). However, there is a problem with the superblocks. Using photorec I have been able to pull some files off that partition, so the data is there and the disk is physically working. So trying the xfs_repair -L option gets me to the situation I can't get beyond: $ sudo xfs_repair -L /dev/sdb6 Note that destroying the log may cause corruption - please attempt a mount The xfs_repair -L option to destroy the log and attempt a repair. If you are unable to mount the filesystem, then use Mount the filesystem to replay the log, and unmount it before $ sudo xfs_check /dev/sdb6ĮRROR: The filesystem has valuable metadata changes in a log which needs toīe replayed. I/O size (minimum/optimal): 512 bytes / 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes Plugging the disk into an SATA->USB caddy on an Ubuntu box. I have a disk from a Buffalo LinkStation that has an XFS partition on it that I cannot mount. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |