I’ve got several hard-drives that are part of my MythTV backend server. MythTV is an open-source DVR that can access as much storage as you can throw at it. With our switch from cable to over-the-air ATSC digital recordings, the amount of available space on our MythTV drives has shrunk dramatically. We’re currently using 4.5 TB out of a total 5.5 TB.
About a year ago I added a 2 TB USB hard-drive as a way to address our disk-space shortage. It worked until about a month ago when MythTV recordings and playback became unstable when accessing the USB drive. Once I narrowed the problem down to the USB drive, I ordered a replacement internal SATA drive with 2.5 TB of space. That came at a premium due to the current global shortage of drives. I began copying data from the old USB drive to the new one as soon as it arrived. I used rsync to perform the copy and began to see errors related to I/O timeouts. This was bad news. I was not going to be able to copy all of the data intact from the old drive, unless perhaps it could be repaired.
I ran the badblocks program to identify bad blocks on the old USB drive and found 900 or so blocks that were flagged as bad. Next, I tried to use the age-old fsck (filesystem check) program to repair the filesystem. Nope, no luck. I was unable to find any information that suggested bad blocks on a JFS filesystem could be corrected. I didn’t think that an event like this would occur, until it did. Fortunately it’s only DVR content and not something more important.
So, I copied everything from the old drive to the new drive using tar, and any files that were unreadable were simply not copied entirely. Not the end of the world. But it still makes me more cautious about using a filesystem like JFS in the future.