Can't read Linux formatted External HDD

almillar

Hold on, XFS, as in the file system that loads of PVRs use? Like Sky boxes?
If you have access to a Windows computer, try running ExPVR to see what you can find on the drive. It's most often used for replacing Sky hard drives, but can do many others. On a similar theme, try Sky Copy+ http://www.skycopyplus.co.uk/ and see if it can get at the recordings.
And on another note, I'm really not keen on using a TV as a PVR, or on 'Smart' TVs in general, but I guess you're coming round to that way of thinking anyway...

rhythmsoup

A little extra on the XFS file system, and probably why your disc is formatted using this

http://www.mythtv.org/wiki/XFS_Filesystem

LucianH

:dance: Sorted :dance:

:beer: Thanks for all your contributions guys :beer:

The fix? In the end so simple and as had been suggested. All I needed to do was run xfs_repair. As you probably sensed from my posts I didn't want to do anything that may have compromised the files and my nervousness had not been helped after I had run the "attempt data rescue" using Gparted (post #20) and it had taken approx five hours to tell me that no file system could be found.

Not seeing other options, I have just ran xfs_repair and within a second or so it came up with this log entry:

Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
xfs_repair: read failed: Input/output error
XFS: failed to find log head
zero_log: cannot find log head/tail (xlog_find_tail=5), zeroing it anyway
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
Phase 5 - rebuild AG headers and trees...
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done

No drama - the drive was automatically mounted and I checked that all files seemed to be there. Connected to TV and now I can watch the drama I had recorded:j

So there you go, don't know why I was so worried. No doubt with Samsung’s software bugs I will have to do this again some time so I will now do a bit of research as to what "failed to find log head" means - any pointers anybody and is there more in the xfs_repair log that gives a clue to what went wrong?

And a final thought: Unimpressed with Gparted - ran for 5 hours and it didn't find the solution! Boy, the things my BH found for me to do around the house while it was running was unbelievable!

debitcardmayhem

LucianH wrote: »

:dance: Sorted :dance:

Thanks for letting us know

-TangleFoot-

LucianH wrote: »

No doubt with Samsung’s software bugs I will have to do this again some time so I will now do a bit of research as to what "failed to find log head" means...

In my experience filesystem errors are often the result of 'improper' shutdown; usually power loss during a write operation.

Kernel_Sanders

LucianH wrote: »

I'm a techie woose - all those command line switches are sooo scary! So I took the easy GUI way out and decided to try the "Attempt data rescue" function in Gparted.

You're not alone, I'm only trying Linux because XP is terminally ill. It's probably of no help, but on Hirens Recovery disc there's something called 'Parted Magic'.