Sysmon slows HDR down so replay drops out.

[linuxtowers]

Thanks Xyz123, looks like I copied the wrong number from sda2, I will try 1932539174 for the start address.
I also see that dc command is using integer maths, which is what we need.

I will try again report back later...

 

[xyz321]

Thanks Xyz123, looks like I copied the wrong number from sda2, I will try 1932539174 for the start address.
I also see that dc command is using integer maths, which is what we need.

I will try again report back later...

No, the start address is 2104515 not 2104512 or 1932539174.

 

[prpr]

Thanks Xyz123, looks like I copied the wrong number from sda2, I will try 1932539174 for the start address.

No, that's the end address, which you don't want.
You were almost right last time - you just used 2104512 instead of 2104515.
You got it right a couple of lines higher up, but fed the wrong number to dc.

 

[xyz321]

humax# debugfs
debugfs 1.41.14 (22-Dec-2010)
debugfs: open /dev/sda2

CTRL+Z

Don't use Ctrl-Z to abort debugfs (or any other app.) This key function does not cause an abort, instead it suspends the program (leaving it in memory) so it could be resumed later. If you were to type 'jobs', you will probably see something like:

jobs
[1] + Stopped                    debugfs
[2] + Stopped                    debugfs

Job 1 could be resumed with 'fg %1', job 2 with 'fg %2' etc.

In general, use Ctrl-C to abort programs.

 

[linuxtowers]

I understand now, my dam typo sorry.

I tried 2104515 this time, and used 'icheck 66039910' to return the inode number of 16507574 and filename path is '/mod/monitor/monitor.db'.

I was originally using Ctrl+C to do the exit, yeah forgot Ctrl+Z puts a task in the background, silly me...
It coming back to me about the jobs and fg.

The thing that confuses me was when I did the 'debugfs' and then the 'open /dev/sda2', I expected the command line prompt 'debugfs:' to come back to indicate the file was open, it just seems to hang, is this normal not to return ?

Also after the debugfs has returned the ncheck path, using Ctrl+C doesn't seem exit debugfs, how do I exit debugfs ?

I made sure the external HDD wasn't connected again, and to give the commands some time to process this time

diag diagmode
reboot

humax# fdisk -lu /dev/sda

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/sda1 2 2104514 1052256+ 83 Linux
/dev/sda2 2104515 1932539174 965217330 83 Linux
/dev/sda3 1932539175 1953520064 10490445 83 Linux

sblock = (int)( (<problem LBA> - <partition start LBA>) * <sector size> / <fs block size>
fsblock = ((530423802 - 2104515) * 512) / 4096

humax# dc
16 o 530423802 2104515 - 512 * 4096 / p
3efb066
Ctrl+C

fsblock = 66039910 (converted 0x3efb066 to decimal)

humax# debugfs
debugfs 1.41.14 (22-Dec-2010)
debugfs: open /dev/sda2

testb 66039910
debugfs: Block 66039910 marked in use

debugfs: icheck 66039910
Block Inode number
66039910 16507574

debugfs: ncheck 16507574
Inode Pathname
16507574 /mod/monitor/monitor.db


What should I do next ?

 

[linuxtowers]

I found that I needed to type 'q' to exit debugfs...

 

[prpr]

I'd be tempted to delete the file, then write to the block. Probably best to uninstall Sysmon first and reinstall it afterwards. See here:

That's good news - the bad sector is not within a file so you can just write zeros to that sector to cause the drive to re-evaluate it and potentially reallocate

humax# dd if=/dev/zero of=/dev/sda2 bs=4096 count=1 seek=66039910

 

[linuxtowers]

I did uninstall Sysmon last night because my box was running too slow, and I was getting my ear bent by the girlfriend because she wanted to watch her fav recorded program.
Also turned off DLNA on the HDR, to stop the HDD clicking all the time last month, the HDD is very quite now.

 

[linuxtowers]

xyz321,

What do you recommend I do next to fix the monitor.db bad sector, should I try and delect the file (if it is still there), or should I use the dd command to zero out the sector, or possibly both ?

I noticed that you had added some useful disk filesystems recover options in the new CFW 2.14, should I upgrade to this or wait till I have tried to clear the bad sector ?

 

[linuxtowers]

Quick update: I have checked the /mod/monitor directory and I can see two files called monitor.db and monitor.db-journal.

I have installed the Betaftpd package to gain root access, and I have successfully uploaded two files without any file read errors, not sure if the the files are OK.

 

[xyz321]

Assuming you haven't tried to delete or modify the file and that sysmon is not running, I would first ensure that your external drive is not connected, then zero out the block using the dd command. Be careful to ensure that the block number is typed correctly since the change can not be undone afterwards. You can delete the file afterwards if you wish.

If you have already deleted the file, then you may have to go through the above procedure again to ensure that the block is not now in use.

 

[af123]

If you haven't deleted the file then the safest way to fix this is to write zeros over it.

dd if=/dev/zero of=/mod/monitor/monitor.db bs=1m count=10

should do it, then check the disk statistics again to see if the pending sector count has gone back to zero.

 

[linuxtowers]

Thanks xyz321 and af123 for your support.

I haven't deleted or modified the monitor.db file, I did uninstall the sysmon package last week.

Wasn't sure if I needed to do another procedure, if the bad sector were found within a file.

I will try the following tonight :

Ensure external HDD isn't connected.

diag diagmode
reboot

dd if=/dev/zero of=/mod/monitor/monitor.db bs=1m count=10

(instead of dd if=/dev/zero of=/dev/sda2 bs=4096 count=1 seek=66039910)

Re-run the smartctl tests to check it has been fixed...
smartctl --test=short /dev/sda
Wait a few minutes to complete...
smartctl -i -l selftest /dev/sda

Or should I run the long test instead ?
smartctl --test=long /dev/sda
Wait a few hours to complete... (I assume it will stop when it found the first error)
smartctl -i -l selftest /dev/sda

Can I run diskattr directly (with no parameters) or do I need to run fix-disk and then this calls diskattr ?

Or can I simply look on the new Webif 'Hard Disc' page, to view the SMART paramters (after running the smartctl --test=short) to check for none zero values ?

197 Current_Pending_sector
198 Offline_Uncorrectable

Then if the pending sector counts are not zero then should I repeat everthing for any other bad sectors (after the long disk test) ?

 

[af123]

I would just look at the new webif Hard Disc diagnostics page. You don't even need to run another short or long test, the numbers should go back to zero once the problem sector is fixed or reallocated.

 

[linuxtowers]

That's very clever, even I can do that.

I have not used the dd command to modify data myself, in this case you say to set the bs=1m option (should it be upper case 'M' ?), will this simply make dd write full 1 megabyte of zero's, 10 times (i.e. count=10) to the monitor.db file.

Will it just make the file monitor.db file bigger (not overwrite any other files with zero's).

 

[af123]

Some versions of dd use upper case and some lower, I can't remember which busybox needs.

Yes, it will just write 10 MB of zeros over the monitor.db file, growing it if necessary. As you're writing over a file, it can't corrupt anything else on the filesystem whereas writing directly to the disk block device (the other dd command) carries more risk.

You'll have to remove the file afterwards as it won't be useful any more.

 

[linuxtowers]

Thanks af123, I understand now, I'm learning all the time.

I ordered a Popcorn hour A400 box (Linux-based media player), so I trying to learn as much as I can on the Humax at the moment.

 

[linuxtowers]

I ran the dd command, but it didn't seem to clear the Pending Sector counts, but the fix-disk results looked better, so I ran a short smartctl and fix-disk, not sure what to do next ?

humax# dd if=/dev/zero of=/mod/monitor/monitor.db bs=1M count=10
10+0 records in
10+0 records out

Then I ran FTP as root user and deleted the /mod/monitor/monitor.db file which was over 10.4M.

I left the other file named monitor.db-journal, as I'm not sure if this is part of the sysmon package...

Then did a reboot, and checked the webif Hard Disc diagnostics page, but didn't see the Pending sector counts cleared, so I thought I will try running the smartctl and fix-disk again.

diag diagmode
reboot

humax# smartctl --test=short /dev/sda
smartctl 5.41 2011-06-09 r3365 [7405b0-smp-linux-2.6.18-7.1] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 1 minutes for test to complete.
Test will complete after Tue Nov 20 17:44:15 2012

Use smartctl -X to abort test.
humax# smartctl -i -l selftest /dev/sda
smartctl 5.41 2011-06-09 r3365 [7405b0-smp-linux-2.6.18-7.1] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Model Family: Seagate Pipeline HD 5900.2
Device Model: ST31000424CS
Serial Number: 9VX18ABQ
LU WWN Device Id: 5 000c50 02d79638b
Firmware Version: SC13
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Size: 512 bytes logical/physical
Device is: In smartctl database [for details use: -P show]
ATA Version is: 8
ATA Standard is: ATA-8-ACS revision 4
Local Time is: Tue Nov 20 17:46:29 2012 GMT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed: read failure 90% 4922 530423802
# 2 Short offline Completed: read failure 90% 4922 530423802
# 3 Short offline Completed: read failure 90% 4869 530423802
# 4 Short offline Completed: read failure 90% 4869 530423802
# 5 Short offline Completed: read failure 90% 4869 530423802
# 6 Short offline Completed: read failure 90% 4839 530423802
# 7 Short offline Completed: read failure 50% 4839 530423802
# 8 Short offline Completed: read failure 90% 4839 530423802
# 9 Short offline Completed without error 00% 3071 -

humax# fix-disk
Checking disk sda

Unmounted /dev/sda1
Unmounted /dev/sda2
Unmounted /dev/sda3

Checking partition /dev/sda1...
e2fsck 1.41.14 (22-Dec-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda1: 15/65808 files (6.7% non-contiguous), 14966/263064 blocks

Checking partition /dev/sda3...
e2fsck 1.41.14 (22-Dec-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda3: 13/655776 files (7.7% non-contiguous), 84826/2622611 blocks

Creating swap file...
Setting up swapspace version 1, size = 1073737728 bytes

Checking partition /dev/sda2...
e2fsck 1.41.14 (22-Dec-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda2: 6187/60334080 files (9.3% non-contiguous), 186548087/241304332 blocks

Finished - type 'reboot' to return to normal operation

 

[xyz321]

I don't suppose you happen to know the original size of the monitor.db file? I am worried that it might have been larger that 10MiB and has now been truncated down to that size.

 

[prpr]

For goodness sake, just do the original write using dd - having done all the hard work to get the block value...