Print

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

[Fatman]

Please do not think for a second I am disagreeing with you fordem, I wholeheartedly agree that we should not be whipping up any hysterias.

I just wanted to make sure that someone voiced an opinion that was serious, but not hysterical, acknowledging that D-Link will look into it.  Cause any discussion here is kinda pointless, the people who have the answers and will be looking into things already have this in their que, our job now is to wait.

I was trying to break the cycle of people only seeing only the half of the posts in this thread.  I smelled hysteria coming in spite of your efforts and was trying to put an end to it by putting forward a 3rd view that is 100% agreeable to both sides.

The reason that the problem showed up in rtorrent is assuredly that the combination of large parallelized writes and hashing everything repeatedly led to any corruption conditions being optimal.  Copies to this device that are later hashed might be a similar condition, though I don't personally believe they would be.

As for the patched race, it is a pretty difficult target, as Linus said, it will probably never be seen in silicon.

[ECF]

kimgkimg
If you are on the fence about returning the item, i would do it immediately.

If you look at this post:
http://forums.dlink.com/index.php?topic=2880.0, you can see that they have been aware of problems almost ever since they released the 1.01 firmware.

That topic was started on nov 11, 2008. It is now late march 2009, and nothing has been done. That gives you an indication of how rapidly they will respond to a problem if it exists. I can't speak to your question exactly, since I put my unit on the shelf a while back, and haven't used it since. I have no confidence in it.

Go look elsewhere for a product that works reliably.

What you are referring to is a bug in the 1.01 firmware and is not present in the 1.00 or our 1.02 b5 beta firmware this has nothing to do with the kernel bug mentioned in this forum.

[JordiBoy]

What you are referring to is a bug in the 1.01 firmware and is not present in the 1.00 or our 1.02 b5 beta firmware this has nothing to do with the kernel bug mentioned in this forum.

Yes, but sandiegocal was referring to the fact that D-Link does not have a stellar track record of fixing know bugs -- bugs that are pretty serious such as losing permissions.  If we can't trust a company to fix problems like the permissions issue in a timely manner, how can we trust that same company to fix corruption issues. 

[peas]

Yes, this was tested with rtorrent because it was discovered with rtorrent, but I have no seen no evidence to suggest that it occurs in the absence of rtorrent - and if it did - there would probably have been a lot more about it in the search engines.

The 1.02 b5 firmware has a torrent client built-in.  Before that, some people were already downloading torrents through fun_plug.  The list of excuses is dwindling.

As Fatman mentioned, rtorrent was merely one way they found of reproducing the issue.  That does not mean it's the only way.

Being a kernel bug, this has the potential to affect every linux distro and embedded device running the affected kernel versions - surely someone else would have experienced it by now.

Erm.. someone has, not just on general Linux distros running the affected kernels, but on the DNS-321.  Sure it doesn't appear to be a common case, but I'd rather err on the side of caution when it comes to my data.

As I believe I've already said, what I'm against is the "whipping up of hysteria" that occurs in these cases - so to speak - do the due diligence rather than simply regurgitating someone else's unsubstantiated hype.

Sounds like the only hysterical one is yourself.  Facts have been presented, but you'd rather ignore them.  Fortunately it appears that the D-Link engineers are investigating this issue.  At the very least they should be able to understand the frequency of this problem.  And I for one am glad that the people at D-Link are more reasonably minded about this.

Perhaps we should all avoid linux because it has race conditions than can potentially corrupt our data

Now don't be silly , all SW/FW have bugs, it's a matter of minimizing the number and severity.

[D-Link Multimedia]

Just to put an end to this. There is NO data corruption in 1.01 firmware for the DNS-321. It has already been tested and verified in lab so if you are running 1.00 and don't want to risk it then move to 1.01.

[fordem]

The 1.02 b5 firmware has a torrent client built-in.  Before that, some people were already downloading torrents through fun_plug.  The list of excuses is dwindling.

None of which are rtorrent - what's your point?

[peas]

None of which are rtorrent - what's your point?

... what's yours?  Don't be ridiculous nitpicking over torrent clients.


To the D-Link technical engineer: Thank you for the update.  Was the kernel updated between 1.0 and 1.01?  Did you confirm the issue in the 1.0 firmware?

[fordem]

Having spent the time to read and understand the discussion between Linus Torvalds et al. - the corruption was caused by a very difficult to replicate (read - extremely rare) IO race condition occuring when a specific torrent client was used - there is no evidence of it occuring with any other application.

That torrent client is not used with this device and the possibility or probability of the IO race condition occuring is slim to nil.

[Fatman]

I thought that is what we had concluded, back before we got our official word we were not effected.

[peas]

Having spent the time to read and understand the discussion between Linus Torvalds et al. - the corruption was caused by a very difficult to replicate (read - extremely rare) IO race condition occuring when a specific torrent client was used - there is no evidence of it occuring with any other application.

That torrent client is not used with this device and the possibility or probability of the IO race condition occuring is slim to nil.

Gosh forden stop threadcrapping.  You don't "understand" the issue at all, you keep repeating one way that someone found to replicate it.  That is not the only way to recreate a timing issue.

But whatever..  What we (as customers) need to know is how the Dlink engineers confirmed that this problem has been resolved, and what their confidence level is with this issue.

[drick]

Just to put an end to this. There is NO data corruption in 1.01 firmware for the DNS-321. It has already been tested and verified in lab so if you are running 1.00 and don't want to risk it then move to 1.01.

just to be clear did you guys also test this on the 323, or is that not needed because they run the same kernel? i'm on fw version 1.07 if that helps.

[D-Link Multimedia]

just to be clear did you guys also test this on the 323, or is that not needed because they run the same kernel? i'm on fw version 1.07 if that helps.

It is being tested across the board. If there are any issues they will be resolved in a timely manner.

[drick]

ok, thanks.

i assume you will post the results to both forums (321+323) as a sticky upon completion, and if there is an issue that will link to a firmware update?

[nickOfTime]

An individual found a data corruption bug by doing copy-compare to the DNS-321 :
http://www.amazon.com/review/R3I00GAEVWL1QZ/ref=cm_cr_pr_viewpnt#R3I00GAEVWL1QZ

D-Link what is the status of this bug?  I'd hate to think that my data is being silently corrupted.

I recently bought a DNS-321 for a secondary backup.  I've owned a DNS-323 for about a year, which I also use for backup.  I read about this bug and set off trying to duplicate it.  I succeeded.  The 321 is running firmware 1.02, and the disk is a Samsung HD103SI.  The bug is exactly the same as described in the Amazon review -- last 76 bytes of a 4k block is all 0's.  This bug does not occur on my DNS-323 (firmware 1.04, WD WD5000AAKS-00YGA).  My PC is a 2-core AMD processor running XP (SP3).

I wrote two little java programs which replicate the bug.

One creates a bunch of files (400, to be exact), alternatively approximately 2MB and approximately 14MB. I used these sizes simply because I found the bug when backing up image files, and these were the sizes of jpeg and raw files, respectively.

The second copies the files in 4KB chunks.

I don't know if 1MB is the magic number that triggers the bug.  And I don't know what size chunks are needed either.  4KB hit the bug.  So did 1MB.  The java version I use is 1.6.0_12.

I put the source code up here: http://snicol.dyndns.org/dlink/

[nickOfTime]

BTW, in backing up about 75GB of image data, I hit this bug 150 times on the DNS-321.  Like I wrote in my previous post, it did not happen at all on my DNS-323.