D-Link Forums
The Graveyard - Products No Longer Supported => D-Link Storage => DNS-323 => Topic started by: mdntblu on March 26, 2010, 05:31:13 PM
-
Ok this is weird. I'm not sure what is going on.
I had to get new hard drives since my other one went bad and I read reviews and decided to just turn them in for new ones while I had warranty.
So I got the NAS all back up and running again.
Loaded the newest Firmware.
Setup everything and see it from my computers.
Then I created all the users, and shares.
Setup the Raid as Mirroring.
Now when I copied the first set of files to it seemed to be super fast over Gigabit.
Now whenever I copy anything I'm getting like 1.50mb/sec and it takes forever to just copy like 4GB. 4GB Should take like 2 min.
Any pointers? Both computers and NAS is setup with Jumbo Frames 4k.
Switch is a Netgear Blue 8-port gigabit switch.
Thanks
Brad
-
I even tried copying a 5mb jpg file from the NAS to my desktop and it is going 24 KB/sec and says it will take 4 min.
On Windows 7 64-bit by the way.
-
I'm sitting on win 7 32bit and currently moving 896.7Gig form a DNS323 at 6.47 to a DNS343, on 1000 LAN with a DGS-1216T in between - don't know if it is worth any thing... :-X
-
Something is clearly wrong, for large files I get around 15-16mbytes/sec to the DNS-323. Other folks claim much faster speeds, but I don't know how they do it. :)
-
ARGH,
I know until this thing crashed several weeks ago and I rebuilt the whole thing it's been slow. I have a Buffalo Linkstation Live LS-CHL right next to it and can transfer a 2 GB movie to it in no time. I know it's the NAS and not my computer/network setup.
Any ideas on what i can do to fix it? I really want to just sell it and buy something else. I've had horrible experience with it and the tech support of d-link is HORRIBLE. They don't want to admit that anything is wrong with their products. I spent close to 4 hours at different times over the course of 5 days with them on the phone trying to get them to just replace the device and they won't do it.
-
Did you do a factory reset? That seems to be a cure-all for a lot of ills this box develops.
-
Factory reset has been done just before I started rebuilding the entire thing.
I have wasted way too much time on this device. So not worth it.
Doing another factory reset and not sure why I have to do a factory reset so often?
-
yeah there is definitely something wrong with this thing. I have just completed another factory reset and a rebuild of the RAID and it hardly let's me copy to it.
Anyone want to buy it?
-
Anyone want to buy it?
I don't think I like the advertising copy. :D
-
Hi, have you checked if the RAID is actually in the process of re-sync ?
A resync will happen whenever the DNS323 is not shutdown from the front panel or the web configuration. The re-sync will consume close to > 80MB/s and everything to the disk will be extremely sluggish. The first file is fast probably because it got cached in the system memory before flushing out to the disk.
If both the HDD activity LED keep flashing even if you did not transfer files to the NAS, it is most likely a resync that is hurting your transfer rate.
-
Hi, have you checked if the RAID is actually in the process of re-sync ?
A resync will happen whenever the DNS323 is not shutdown from the front panel or the web configuration. The re-sync will consume close to > 80MB/s and everything to the disk will be extremely sluggish. The first file is fast probably because it got cached in the system memory before flushing out to the disk.
If both the HDD activity LED keep flashing even if you did not transfer files to the NAS, it is most likely a resync that is hurting your transfer rate.
Where did you come by this quaint notion - in three plus years of owning a DNS-323 in a RAID1 configuration, I have NEVER had it resync on power-up after an improper shutdown. I could also be wrong on this, but 80MB/s?? I don't think the disk interface can deliver that much throughput.
-
After a crash shutdown (removing the power), I've seen it think about the array for a short period, then decide it was OK.
-
Well, if the power was removed suddenly when none of the drive is writing, you are lucky. Otherwise, you bet there will be a re-sync. In fact, prior to 1.08, the ext2 will also likely need a fsck. If you do not trust me, try it out, it is not very difficult to duplicate this one ;D
On the 80MB/s: yes, DNS323 can sync at this rate with 7200rpm SATA2 drives. You can observe this only by getting into the box and checking out /proc/mdstat. In fact, this is one of the strength of the DNS323 SATA controller. On a typical PC with a PCI SATA controller, one can easily expect about 75MB/s re-sync with 7200rpm SATA2 drives, the bottleneck is the PCI bus.
-
Well, if the power was removed suddenly when none of the drive is writing, you are lucky. Otherwise, you bet there will be a re-sync. In fact, prior to 1.08, the ext2 will also likely need a fsck. If you do not trust me, try it out, it is not very difficult to duplicate this one ;D
You missed my point - been there, done that - and unless there has been a change made to the firmware recently (1.06 or later), it does not resync, and does not do an fsck at power up as most linux distros do.
On the 80MB/s: yes, DNS323 can sync at this rate with 7200rpm SATA2 drives. You can observe this only by getting into the box and checking out /proc/mdstat. In fact, this is one of the strength of the DNS323 SATA controller. On a typical PC with a PCI SATA controller, one can easily expect about 75MB/s re-sync with 7200rpm SATA2 drives, the bottleneck is the PCI bus.
Again been there, done that, and if I recall correctly, the numbers are significantly less.
-
You missed my point - been there, done that - and unless there has been a change made to the firmware recently (1.06 or later), it does not resync, and does not do an fsck at power up as most linux distros do.
I take that back - with 1.09 it does resync - earlier versions did not, I'm not certain when this was added.
-
Well, at least at 1.05, 1.06 and 1.08, I have seen it re-sync, can repeat this anytime. As far as I know, this is a kernel feature, and Dlink has not updated the kernel for a long time. If DLINK had done anything to change this behavior of re-sync and fsck, then, the data in the RAID1 array will never be able to guarantee integrity. As far as I know, Linux md driver do not have any facility to disable 'resync' because it is a dangerous thing to do (read details of md options here: http://www.gelato.unsw.edu.au/lxr/source/Documentation/md.txt (http://www.gelato.unsw.edu.au/lxr/source/Documentation/md.txt)).
I think there may be a confusion about Auto-Rebuild in the configuration menu and re-sync. I believe DLINK's 'rebuild' means partitioning and 'formatting' the drive. Formatting only make sense when the drive inserted is not part of a RAID1 array. If the drive is meant to be a spare disk for a degraded RAID1, then, 'rebuild' only mean partitioning and hot add the spare disk in the RAID1 array. The md driver will take over from there to perform the resync, where the resync status can be seen on the status page.
If DLINK wants to make live less stressful for all, then, update the kernel, and allow option to activate 'write_intent_bitmap' for those who care more about data integrity and willing to suffer yet a little more performance, all in the name of avoiding lengthy re-sync, especially for large capacity drives.
Anyway, this is besides the point - I was trying to alert that by design, the RAID sub-system of Linux does re-sync when any writes to any disk component that is part of a raid array was lost before the commit set is able to fully complete. Why you had not seen it re-sync is most probably that a write was not pending, so you were lucky. It takes a write to RAID array at the time of power trip to result in 'mismatch'.
Even more important point I was alluding to the fact that ext2 by design will need a fsck if the power is lost without a proper shutdown. This is the major flaw in ext2 design, and thereafter the journalling was added to ext3 to fix this deficiency and annoyance.
If RAID1 array host a ext2 file system, a RAID level re-sync is not sufficient to assure integrity of data. In fact, it is very dangerous - files may ended up cross -linked badly.
Firmware prior to 1.08 does not have means to 'scandisk'. If the internal file system is left at ext2, i.e. not migrated to ext3, then, whenever power trips, it is highly advisable to scandisk. Otherwise, do frequent backup, but be very careful whether you are backing up files that have already been crossed linked. In other words, the backup may succeed, but what went in are actually corrupted versions of files.
If data integrity is top of your list, then consider reconfiguring the RAID1 array to host ext3 file system. However, be aware that you loose some performance, this is the price you pay - buy data integrity with some throughput. For most real-world applications, the little lost in performance is insignificant.
On the throughput, yes, in fact, all 4 of my DNS323 does the job at at 89MB/s sustained throughput when re-sync'ing. However, note that this rate is achievable for the first 40% of the disk capacity, then, it will gradually drop by 10% towards the higher end of the capacity rating. To re-sync fast, you must not have any service running, especially services like FireFly, any disk activity on the RAID will affect the throughput. Therefore, to swap out a disk from RAID array, it is best done when none of the services are needed.