Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
I have just had my DNS323 repaired by D-Link to replace a faulty hard disk LED. It was originally set for RAID 1, and there was one mirrored partition Volume_1.
On replacing my disk drives and powering up, I now have 2 partitions, Volume_1 and Volume_2. What I want to do is rebuild the RAID 1 array using mdadm, without losing the data on the hard disks.
I have a backup of my data on another external drive, but the D-Link admin tool solution seems so inelegant, where you have to set the RAID type, re-format and then restore from the backup. All when the data still resides on my hard drives.
How can I create the RAID array with Volume_1 and then synchronize the second disk? My firmware is 1.03, and I have the telnet fun plug running.
Offline
you can try this
http://www.aroundmyroom.com/2008/01/07/ … id-status/
same applies probably for dns323
but only if the device tells you it's in degraded status. I do doubt if it's possible to have it working if the device does not find any raid stuff.
Offline
Errr - usual warning about messing about with your dns-323 - I take NO responsibility for your actions blah blah blah
Looking at /etc/rc.sh the dns-323 seems to do things a bit strangely... it appears to run a "hd_verify" command which reads /etc/raidtab and sets up the array. If I run hd_verify command while the dns-323 is running and the mirror is mounted I get the following output (with errors obviously!):
/etc # hd_verify Serial Number = 9QG3WQA8 Serial Number = 9QG3VS0B Raid Table Parser version v1.04 mdadm: chunk size ignored for this level mdadm: Cannot open /dev/sda2: Device or resource busy mdadm: Cannot open /dev/sdb2: Device or resource busy mdadm: create aborted Raid Level Parser version v1.01 mdadm: Cannot open /dev/sda3: No such device or address mdadm: Cannot open /dev/sdb3: No such device or address mdadm: create aborted Raid Level Parser version v1.01 Build Shared Name Table version v1.05 Refresh Shared Name Table version v1.04 mdadm: fail to stop array /dev/md0: Device or resource busy
Using strings on the hd_verify binary we see some interesting stuff - especially the fact that it calls a script called raidstart (a LOT removed):
/etc # strings /usr/sbin/hd_verify /dev/md0 RAID0 Disk reuse touch /tmp/hd_verify_warning RAID0 Disk exchange touch /tmp/hd_exchange /etc/hotplug/satamount /dev/sda2 sda3 /dev/sdb2 sdb3 /etc/hotplug/sataumount /etc/raidtab2web /proc/partitions sda2 sdb2 /etc/hotplug/hiddenmount sda2 size != sdb2 size /mnt/%s/%s/hd_magic_num umount %s raidstop md0 md1 disk reuse mount device %s fail HD magic num error raidstart /etc/mtab mount -t minix /dev/%s /sys/mtd1 cp /default/hd_magic_num /sys/mtd1 umount /sys/mtd1 Serial Number = %s /tmp/onedisk cp /tmp/onedisk /sys/mtd1 cp /tmp/onedisk /sys/mtd2 rm -rf /tmp/onedisk
Looking in the /sys/crfs/sbin/raidstart script we see a few interesting things also, ie.: the fact that we're parsing raidtab and building the array:
/etc # cat /sys/crfs/sbin/raidstart |egrep '/etc/raidtab|mdadm' RAIDCONFIG=/etc/raidtab mdadm -Cv /dev/"$1" -l0 -n2 /dev/"$3" /dev/"$4" mdadm -Cv /dev/"$1" -l0 -c"$3" -n2 /dev/"$4" /dev/"$5" mdadm -Cv /dev/"$1" -l1 -n2 /dev/"$3" /dev/"$4" mdadm -Cv /dev/"$1" -l1 -c"$3" -n2 /dev/"$4" /dev/"$5" echo "mdadm raid_device raid_level chunk_size device1 device2" echo "mdadm md0 raid[0|1] 4 sd[a|b|...] sd[a|b|...]" mdadm -Cv "$RAIDDEV" -l"$RAID_LEVEL" -c"$CHUNK_SIZE" -n"$NR_RAID_DISKS" "$DEVICE1" "$DEVICE2" FileSystem=$(grep EXT2 /etc/raidtab2web) #+Wilson01102007 /etc #
So, creating the mirror manually may be as easy as mounting the 2 mtdblocks read/write (e.g: mount -t minix /dev/mtdblock0 /sys/mtd1), creating the /etc/raidtab and rebooting. However I have no idea what will happen if the disks data are different (i.e: if it will resync, think it's ok but have half a degraded mirror, fail completely!). For reference my raidtab is as follows:
raiddev /dev/md0 raid-level raid1 nr-raid-disks 2 chunk-size 64 persistent-superblock 1 device /dev/sda2 raid-disk 0 device /dev/sdb2 raid-disk 1 raiddev /dev/md1 raid-level linear nr-raid-disks 2 chunk-size 64 persistent-superblock 1 device /dev/sda3 raid-disk 0 device /dev/sdb3 raid-disk 1 Version 1.3
And don't ask why it creates md1 on slices sd[a|b]3 which don't exist - I have NO idea!
/ # /mnt/HD_a2/fun_plug.d/bin/fdisk -l |egrep 'sd.3' / #
Last edited by HaydnH (2008-02-18 18:46:59)
Offline
Thanks for that. Checking raid status gave me this:
# cat /proc/mdstat Personalities : [linear] [raid0] [raid1] unused devices: <none> # #
Device /dev/md0 is not active, and the /etc/mdadm.conf file is empty. If I created the config file, could I use the assemble or add options to rebuild the array?
# # mdadm --examine --scan /dev/sda2 ARRAY /dev/md0 level=raid1 num-devices=2 UUID=fd76e1c2:74f3c941:166bdd47:ed94036f # # mdadm --examine --scan /dev/sdb2 ARRAY /dev/md0 level=raid1 num-devices=2 UUID=fd76e1c2:74f3c941:166bdd47:ed94036f # # # mdadm --detail --scan # # #
Offline
notbear - I applaud your approach to understanding mdadm and how it works.
On the DNS-323, (I believe), there are several start up D-Link scripts which leave
trace text files on the file system to signify success for failure of raid setup.
I'm not sure when these trace files are created, or if they are stored in NVRAM or recreated
each boot up. I believe (just a theory) after the repair of your unit, these trace files were missing,
which caused the D-Link start up scripts to "determine" you were not running a RAID.
Here is a listing of /tmp where (I think) some of the trace file may be written:
/tmp # ls -la drwxr-xr-x 3 root root 1024 Feb 18 22:34 . drwxr-xr-x 18 root root 1024 Dec 21 00:47 .. -rw-r--r-- 1 root root 5 Dec 21 00:46 CustomID -rw-r--r-- 1 root root 0 Dec 21 00:46 GetTimeServerFinish -rw-r--r-- 1 root root 91 Dec 21 00:46 QuotaStatus -rw-r--r-- 1 root root 0 Dec 21 00:46 boot_finished -rw-r--r-- 1 root root 5 Feb 18 22:31 fan_status -rw-r--r-- 1 root root 62 Dec 21 00:46 fchmod -rw-r--r-- 1 root root 0 Jan 29 00:06 format_error -rw-r--r-- 1 root root 0 Jan 30 23:35 format_result -rw-r--r-- 1 root root 0 Dec 21 00:46 ftprun -rw-r--r-- 1 root root 17 Dec 20 16:46 makaddr -rw-r--r-- 1 root root 1 Dec 21 00:46 max_dl_num -rw-r--r-- 1 root root 0 Dec 21 00:46 md0 -rw-r--r-- 1 root root 0 Dec 21 00:46 md0_active -rw-r--r-- 1 root root 1 Dec 20 16:46 onedisk -rw-r--r-- 1 root root 0 Dec 21 00:46 opserver_frodo -rw-r--r-- 1 root root 0 Dec 21 00:46 raidup -rw-r--r-- 1 root root 0 Dec 21 00:46 re-sch drwxr-xr-x 2 root root 1024 Feb 18 22:28 samba -rw-r--r-- 1 root root 0 Dec 21 00:46 sda -rw-r--r-- 1 root root 0 Feb 18 02:05 sntp_ok -rw-r--r-- 1 root root 0 Feb 18 02:05 stime_ok -rw-r--r-- 1 root root 4 Dec 21 19:09 temper -rw-r--r-- 1 root root 3 Dec 21 19:09 temper_C -rw-r--r-- 1 root root 4 Dec 21 19:09 temper_F -rw-r--r-- 1 root root 147 Feb 18 22:32 web_chk -rw-r--r-- 1 root root 0 Dec 21 00:46 webs-reload
You might find that you can get the /dev/md0 started with mdadm command, however,
upon reboot (without these trace files) your DNS-323 may not restart the RAID.
Please don't take this information as discouragement, it's only a theory, since I do not
fully understand all the details of the proprietary D-Link scripts. Continue along your line
of thinking, I'm very interested to know if your procedure is successful.
Make sure you test the reactivated RAID can survive a reboot, before you declare success.
Last edited by mig (2008-02-19 08:52:58)
Offline
Notbear - The dns-323 doesn't use mdadm.conf, it uses raidtab (see above) - at least this is correct as of firmware 1.03, they may have changed it at 1.04 but I doubt they'd go through the hassle.
Mig - The text files are created by the hd_verify binary (see the strings output in the second code box of my above post) and the raidstart script. Both seem to take the raid setup from raidtab - however I am unsure what the scripts will do if the 2 halves of the mirror are not synched.
Notbear - in light of the above (and because you have a backup) I would be very interested to see what happens if you create the raidtab (you must make it a permanent add using the mount command) and reboot . However, I'd like to check how the reset button works first - there appears to be 2 mtdblocks used (/dev/mtdblock0 & /dev/mtdblock1) containing these files, so I assume the default boot uses one and a reset copies the data from the other over the default one which would provide a safe way of checking this ... but without finding out for sure I wouldn't want to hand edit this kind of thing! Has anybody researched this?
Offline
Notbear, could you check the partition table with fdisk on a linux PC (fdisk in dns-323 is broken)? See if the partition type is fd?
Can you get at least one of the disks to start up in RAID (cat /proc/mdstat)? I have managed to recover from a similar issue in the past but my notes went missing :-(
Offline
Can someone with RAID1 setup on FW 1.04 post their /etc/raidtab + /etc/raidtab2web files (as well as the size of their drives, etc)? I think the copy in /etc is fine; although it has to be edited in /dev/mtdblock0.
I have the same problem (restored RAID-1 drives to a new DNS-323) and am working on fixing it manually. The info above is almost enough; but I'd rather not keep guessing on the exact settings for the raidtab2web file which wasn't posted above.
I'll post the procedure I used once (if) I get it working...
IMO; D-Link has a major gap here for a reliable solution! While I don't mind hacking this thing up; I would have expected that 1 good disk from a RAID-1 set + one backup config file from the DNS-323 webui should have allowed a fully recovery in a brand new DNS-323 without any hacking, reformatting, etc. As long as I have a good copy of the data - I should have a supported recovery mechanism!
Thanks,
Jeff
Offline
Drives are 250 MB Seagate 7200.9 Baracudas
Offline
Kicking a dead horse probably but I have recently tried this with a DNS-343.. I have those WD 'advanced format' drives and had to try and repartition them to make them run efficiently.
http://dns323.kood.org/forum/viewtopic. … 805#p35805
This was the thread I've been in trying to get it to work. My last post basically said that I let the Web-interface make the RAID-5, funplugged in and stopped the raid, repartitioned, got the raid up and running..
I used raidstart and it sure enough mounted my raid to HD_a2 and left a 'raidup' tag in /tmp...
Checked the web interface and it was properly reporting my RAID again.
Everything was fine but of course my luck.. I didn't survive the reboot.
Any new insights on what I could have done differently? It is a huge pain in the ass as this whole process took quite a few hours to get up and running with the correct partitions for these silly WD EAR drives.
Offline
caust1c wrote:
Kicking a dead horse probably but I have recently tried this with a DNS-343.. I have those WD 'advanced format' drives and had to try and repartition them to make them run efficiently.
...
Any new insights on what I could have done differently? It is a huge pain in the ass as this whole process took quite a few hours to get up and running with the correct partitions for these silly WD EAR drives.
I guess you mean 4K sector drives? don't waste time optimizing that. Yes it's true, without approciate aligment, performance of 4K drives is degraded (smiliar with SSDs), but in this case you wont notice any difference, because the DNS-323 / DNS-343 themselves are much tighter bottlenecks.
Offline