Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[nickOfTime]

Yes in general it's best to verify data.  In this specific case the act of verifying data to the DNS-321 causes data corruption, whereas not verifying is unlikely to cause corruption.  The typical procedure is to write and immediately verify that file, as opposed to writing all files then verifying from the beginning (more efficient code-wise not having to store the entire list or reload it).  I understand your sentiment but in this case what you're condoning will directly lead to data corruption.

First of all, I agree with you to turn off verify.  If you are using backup software that you have no control over how verification works, you don't know if the way it verifies will trigger the bug or not.  In all likelyhood it will trigger the bug.

Having said that, while backup software that verifies afterwards is theoretically a little less efficient in terms of RAM use, but in real terms it doesn't make a difference.  It is no less time efficient.

Most backup software first scans the source disk before doing any create/modify/delete operations, and creates a list of the files in memory.    Verify is by hash (CRC32, MD5, or if you are really nuts SHA-512) and length. All you need to do to verify afterwards is to store the hash and length of the source file, then read and hash the destination files after all writing is complete.  In my case it adds a whopping 24 bytes (16 byte MD5 + 8 byte length) to each record.  Even if you are changing a million files. that's an extra 24MB of RAM consumed.  Not a huge deal when even cheap PCs ship with 4GB of RAM.

It took me about an hour to change and test my backup software after I replicated the bug.  It runs just as fast (or slow, considering it's writing to DNS-323 and DNS-321) as ever.

[nickOfTime]

I've been testing the 1.03 firmware beta 9 and it seems to work.  Thanks!

[peas]

That is great news.  Kudos to D-Link for working on this issue.  That said, I wonder why the fix wasn't included in the original b9 release notes.  Did DLink update the kernel?  Or is there another Linux patch that addresses this?  I'd rest easier knowing that this was a targeted fix, and not merely a by-product of other changes.  The latter is ****e to bugs resurfacing in later revs.

Edit: lol the silly DLink censor thinks "p r o n e" is a bad word because the first 4 letters match a slang version of a "bad word".  Man I hope DLink's other programming is better than this web site.

[nickOfTime]

That said, I wonder why the fix wasn't included in the original b9 release notes.

It is...

http://forums.dlink.com/index.php?topic=4747.0

[peas]

Ah, you're right.  I saw your post in the beta forum correcting the release notes (it wasn't listed initially in that post).  But that thread was updated after the main release notes thread, not the other way around, hence my confusion.

Turns out that 1.03 b9 is running kernel 2.6.22.7.  From a telnet console via fun_plug, use the command:
echo `uname -r`

It would have been helpful if DLM mentioned that the kernel had been upgraded beyond 2.6.19 (the last version with that data corruption bug).  In any case, I'll rest easier knowing that this particular issue is no longer a threat to my data.

[bitbrain]

After a small amount of research (Amazon.com user reviews), I became quite concerned about this issue.  I am a computer savvy individual, who intends to copy AND VERIFY my files to the NAS.  Please confirm this issue is fixed in the latest and greatest firmware.

thanks
-bb

[mzpx]

What confirmation do you expect? (And from whom?)
The box is running kernel 2.6.22.7, that I can confirm.
If the problem was resolved in that kernel (as it was stated) then you are covered.
Problems that exist in the 2.6.22.7 kernel, but not in later ones are probably included.
DLink is not a Linux kernel developer, I would not expect them to issue patches.
If you need that, you are better off with a mainstream distro on generic hardware.
Sorry.
p.s. If the problem exists, it does not seem to have affected a lot of users and this seems to be the only thread in this forum about this topic and it was not touched by anyone since august. I do not read people complaining about data loss either, but then - most of us does not verify the data.