Recover Recordings instead of Formatting HDD

@prpr If those were the two options, then your logic is sound.

There is also the option that the disk isn't toast, but it acts toasty within the Humax, and the Humax doesn't have the tools to un-toast it. If it could be recovered outside the box, *and* the Humax could happily host a new disk, then @Ezra would be right. There are, of course, plenty of dubious conditions to make that true.

I've largely decided that there isn't anything that isn't going to be able to get this disk to recover within the Humax, and very likely isn't anything that would get it working outside either.

So, I bit the bullet, and asked the Humax to format the disk. It sat with a spinning "processing..." popup (which I left for 3 hours) but nothing appeared to happen. The box hadn't crashed (I could telnet in) but was unresponsive to the remote. Typing reboot certainly worked...

On going back into maintenance mode nothing had changed. /dev/sda1 still behaved like it was slightly there, but mostly not. The other devices acted like they were still missing.
Nothing lost, nothing gained.

I assume that 3 hours should be long enough to format a 1TB disk?

This time, I did try the "tune2fs" command, which gave a little output for sda1 (I guess the superblock is in the first few disk blocks):
Code: 
humax# tune2fs -l /dev/sda1
tune2fs 1.41.14 (22-Dec-2010)
Filesystem volume name:  <none>
Last mounted on:          <not available>
Filesystem UUID:          8145e83b-c55b-43de-8cfb-5b8d738b2d68
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Filesystem flags:        signed_directory_hash
Default mount options:    (none)
Filesystem state:        clean
Errors behavior:          Continue
Filesystem OS type:      Linux
Inode count:              65808
Block count:              263064
Reserved block count:    13153
Free blocks:              249610
Free inodes:              65795
First block:              0
Block size:              4096
Fragment size:            4096
Reserved GDT blocks:      64
Blocks per group:        32768
Fragments per group:      32768
Inodes per group:        7312
Inode blocks per group:  457
Filesystem created:      Sat Jan  1 00:00:16 2000
Last mount time:          Sat Jan  1 00:00:18 2000
Last write time:          Sat Jan  1 00:00:18 2000
Mount count:              439
Maximum mount count:      33
Last checked:            Sat Jan  1 00:00:16 2000
Check interval:          15552000 (6 months)
Next check after:        Thu Jun 29 01:00:16 2000
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:              256
Journal inode:            8
Default directory hash:  tea
Directory Hash Seed:      99dea4e5-547b-4367-9e68-a5bdfd08779a
Journal backup:          inode blocks
humax#
 
The Humax only does a quick format which should take a few minutes. It may be possible to force a full format using Telnet, but it looks like you know a lot more about Linux than I do.
 
What's the point in messing about with filesystems when you know the disk is generating millions of bad block errors on read?

"quick format", "full format"... OMG

<shakes head and sighs>
 
Clearly the OP is trying to reformat the disk and the Humax has failed to do so. In the past I have found, in some cases, that it can be persuaded to reformat by first connecting the drive to a Windows PC, quick formatting in NTFS, changing the drive space to unallocated and then reconnecting to the Humax. This is inelegant, but is quick and it works. As the OP's unit is still under warranty he can't do this but a full format might do the trick. We don't know for sure that the disk is FUBAR. Personally, I'd send it back to Humax, but as the first thing they will do when you phone them is to tell you to reformat the drive so why not do it up front if you can?

@Prpr: you are clearly a knowledgeable person and you have taken the trouble to help me in the past, for which I am grateful, but why do you resort to rudeness so quickly? You must realise that rather than making a point you just diminish your own standing.
 
If you are able to remove the drive from the box this is your best bet -
(remember an exposed PSU can still bite you even if unplugged)

connect the drive to a PC
run partedmagic and delete all partitions (dont do it under windows)
repartition the drive
format all 3 partitions using the correct commands (someone kindly put them in this forum somewhere -a search will pull them up)
(dont worry about getting the exact partition sizes - doing it close is good enough)
run a full surface scan - leave it overnight if you have to (dont know how long on your drive)
stick it back in the box

If it fails at any point during that process it's dead.
 
@MontysEvilTwin

Thanks. I didn't recall it taking very long when I first got the Humax. A recent mkfs on a standard Linux box, for a 2TB disk, was IIRC a 20-30 minute job.

@prpr

I agree that the badblocks program reported lots of bad blocks, but I'm pretty sure that there aren't actually all those bad blocks physically on the disk surface. My belief is that there is something wrong with the way in which the Humax system board is attempting to communicate with the disk, and that some (extremely rare) problem is baulking this communication in a way that *appears* like bad blocks (ie the badblocks reports are a symptom, but not the cause). The fault could be a component on the system board, disk controller board, disk head or indeed the disk surface. It could be a cable or connector. Whatever it is, I suspect the kernel is having a paddy when dealing with it, and leaving things in an inconsistent state for user-level programs to deal with. So I treat the errors from the user-level programs, including badblocks and mke2fs, as just showing symptoms.

The strangest thing is that the system board obviously manages to read sector 0 at some time, as it gets the partition data; the block can't be sufficiently bad to make *this* read fail (it manages this part on every boot). But I cannot read the same sector using the simplest low-level commands that I know (I don't think it gets much simpler than 'dd' reading a single sector at a time). Likewise the fact that some sectors are readable via device /dev/sda1, yet those same sectors are not readable via /dev/sda, which they *ought* to be.

So whatever the fault is, it is not a permanent hardware fault. But it isn't a consistent fault.

I do have plenty of experience of Linux, but that's on PC where I can open the box. On the Humax, my skill counts for little when I can't even find the kernel debug log. I have a fair amount of experience of dealing with bad disks (ddrescue is a great tool for coping with real bad blocks), but right now I feel like I have one hand tied behind my back because of a lack of kernel information, and the other one tied behind my back by the warranty requirement to not open the box.

What's the point in filesystems and formatting?

As MontysEvilTwin points out, the first thing that the support guys will ask when I call is whether I have done what the popup asks - to format the disk; to them, I know nothing else about how to recover other than performing this step. I didn't want to do it, but once I bit the bullet and decided to do the format, I also believed it wouldn't work. It was no surprise that it failed.

So, I've pretty much decided that the box is going back. It is killing my curiosity though.

@jack616
That's the kind of thing I'd do if I could open the box, though I'd probably use tools on a Linux SystemRescueCD instead.
 
You must log in or register to reply here.
Back
Top