DSM-G600, DNS-3xx and NSA-220 Hack Forum

Hi Mig,

mig wrote:

jayas wrote:

It looks like D-LINK is happy to work out what is wrong on its own without help offered ... so lets just sit tight wait to see what 1.05 brings.

jayas, It looks to me, from this post http://forums.dlink.com/index.php?topic … 80#msg7880
that D-Link has not even acknowledged this problem and perhaps some help would be
of assistance.

Sorry I cannot read that message because it is "missing or offlimits" to me, and I kinda don't feel like going on to yet another forum.  I recall DLINK in this forum said I should try that 'official' forum and I gave up for that reason.

[digression]

I looked into this a while ago when my Seagate drives would not format successfully.  There were two problems in my case: one of the disks had too many bad sector mappings.  This means disk does not report errors but you hear the clicking sounds.  The script that formatted the disks appear to not cope with this.  My solution was to format it myself using fun_plug.

Then I looked into why hot-swapping was not supported.  DLINK support (in Australia) said this is because the chipset used does not support it.  I did not believe it and decided to play with the scripts.  I got to the stage where if we ignore the error message emails and drive lights, I could get a hot plugged drive to work without having to power-cycle the DNS-323, except that it appeared as a different drive, namely /dev/sdc.  It looked like sata hotplug scripts were the problem.

I tried to understand /etc/hotplug/sataumount and my understanding is reflected here:

#!/bin/sh

# debug log
date >> /dev/HD_a2/fun_logs
echo $0 >> /dev/HD_a2/fun_logs

# manifests
scsiInfo=/proc/scsi/scsi
idString=abcdefghijklmnopqrstuvwxyz

# parameters
diskPath=$(cd /sys/custom/shared_name/HD; echo *)
diskName="Volume_"

# unmount sata disks ...
hostNo=0
diskNo=1
while   [ $hostNo -lt 2 -o -n "$attach" ]
do
        # for each disk attached to host adapter ...
        count=$(grep -c "Host: scsi$hostNo" $scsiInfo)
        while   [ $count -gt 0 ]
        do
                # establish disk ID
                diskId=$(expr substr $idString $diskNo 1)

                # unmount the disk
                mount=
                retry=0
                while   [ $retry -lt 5 ]
                do
                        # check if mounted ...
                        check=$(mount | grep /mnt/$diskPath$diskId)

                        # if not mounted ...
                        [ -z "$check" ] && break

                        # get mount path
                        mount=$(set - $check; echo $3)

                        # attempt lazy unmount
                        umount -l $mount

                        # on subsequent retries ...
                        [ $retry -ne 0 ] && sleep 1

                        # iterate loop
                        retry=$(($retry+1))
                done


                # if disk was not mounted ...
                [ -z "$mount" ] && break

                # if disk was unmounted ...
                [ -z "$check" ] && rm -fr $mount

                # delete all names for disk
                baseName=$diskPath$diskId
                deltbl $diskName$diskId $baseName >/dev/null
                index=1
                while   [ $index -lt 17 ]
                do
                        deltbl $diskName$index $baseName$index >/dev/null
                        index=$(($index+1))
                done

                # delete markers
                rm -f /tmp/HDDBlackList_$diskId
                rm -f /tmp/sd$diskId$hostNo
                rm -f /tmp/havedev
                rm -f /tmp/sata*

                # iterate loop
                diskNo=$(($diskNo+1))
                count=$(($count-1))
        done

        # iterate loop
        hostNo=$(($hostNo+1))
        attach=$(grep scsi"$hostNo" "$scsiInfo")
done

# return success
exit 0

I gave up when I tried to extract the requirements for /etc/hotplug/satamount ...

I told DLINK these scripts need attention pronto.  I also told DLINK Australia about myself.  I said I am able to help get the scripts done properly.  DLINK Australia thanked me very kindly for my offer, but said that as much as they appreciated my offer of help, there was really no channel between DLINK Australia and the development team that enabled them to faciliate this.  For what it is worth, the support guy at DLINK Australia was great.

I tried a few more things I played with, like making the lights change to amber, but I eventually found out things just latched up and there were just too many unknowns and I cannot do this without some help from DLINK as to what the requirements are or what this piece of code is really supposed to do.

[end digression]

So this is the state of things ... and I am hoping someone (who could write good clear shell scripts) will have cleaned up these scripts in 1.05 firmware.  I have not worked out how to hook the scripts to the firmware if I sat down and fixed them all.

This is pretty much the situation from my perspective.

Kind regards,

Jaya

PS:  I am having somewhat serious RSI issues at the moment, so I apologise (to myself!) for putting up such a long post, and without reading it back even.

Maybe this isn't as isolated as suggested in some posts. Just thought I'd add lmy experience. I recently upgraded to 1.04 and now see the amber ligh on the left drive (it actually looks pink). I have two 1TB drives installed with 500GB RAID1 and  1TB JBOD. When reading or writing to either volume the left drive light changes to blue. When not being accessed the light changes back to pink. I also get the "degraded" status for sync time remaining. D-Link tech support indicated they had never heard of a pink light or the "degraded" status and recommended replacing the drive.

Last edited by jacksoncage (2008-05-03 01:50:33)

Hi Jacksoncage

jacksoncage wrote:

Maybe this isn't as isolated as suggested in some posts. Just thought I'd add lmy experience. I recently upgraded to 1.04 and now see the amber ligh on the left drive (it actually looks pink)... D-Link tech support indicated they had never heard of a pink light or the "degraded" status and recommended replacing the drive.

Here is my take on the amber/pink light issue:

Amber light comes on when DNS-323 (rightly or wrongly) determines that a disk is faulty.  When amber light is off the blue light indicates disk is functional and flickers when there is activity.

When the amber light is on, the blue light is not supposed to come on.  When it does, this is when the amber light appears pink.

I believe the pink light is s clear indication that DNS-323 is confused as to whether or not the disk is faulty.  One half of it (that drives the amber light) says it is, but the other half (that drives the blue light) thinks all is okay.

Now I can create the amber and pink light scenarious by simply creating certain files used by DNS-323 for communication between its various components -- so I know what the amber light looks like with and without the pink light.

The only real way to get to the root of this problem is to look at the the components that deal with hotplug and communication schema between these components and the part of the system that activates the lights.

Regards,

Jaya

Last edited by jayas (2008-05-03 09:51:04)

Just for the stats, I up(down?)graded to 1.04 last night and I too noticed a few minutes after the light of my right drive turning pink and the status going as "downgraded"

I've got 2 Samsung Spinpoint T166 S-ATA - 500 Go - 16 Mo drives.

T.

Last edited by tsourbier (2008-05-09 13:06:35)

Hi all,

This is great - I've just bought a couple of DNS-323s for clients and one is experiencing this very issue, so thank goodness for Google and you guys!

After reading this whole thread, I'll take a stab at adding the unit's config to this discussion, in the hopes it may trigger something:

*  DNS-323 hardware B1
*  Firmware 1.04 (Australasian version, if that helps?)
*  Upgraded firmware from 1.03 straight out of the box, even before putting any drives in
*  2 x Seagate 750GB ST3750330AS
*  Configured as a (approx) 200GB RAID 1, with 1TB JBOD
*  Left running it seems OK, but power-down and then power-up again gives amber light on a seemingly random drive
*  Re-formatting drives fixes problem (can power-down/up normally) but putting any data on JBOD volume will cause issue
*  RAID 1 volume has not had any data put onto it, but it will still be listed as 'degraded' if the unit is powered-down and then powered-up  (only data on it is the 28KB it mentions in the webgui - I guess this is used by the OS)
*  I haven't installed any fun_plug (I'm still trying to work out what it is used for!)

Are we thinking the drives are safe and are being incorrectly reported by the DNS-323 as faulty?  Or should we return the drive(s)?

Anyone else had any new theories or trouble-shooting ideas about this?  And is it true that 1.05 is now out (living in New Zealand I was told we should wait for an Australasian firmware version update, not to use a US one - does this sound valid?)?

Thanks!

Last edited by BravoNZ (2008-06-19 11:40:53)