QNAP firmware issues : Major file system bug

[BloodShed]

Please notice that this setting requires a switch with a static trunk configured...

Thanks P3R. I merely wanted to point out that I have tried several aggregation options (including disabled with a single port) during troubleshooting which have made absolutely no difference to my situation. In fact, I was originally using balance-alb when this problem started.

[Slade]

Thanks for your work in bringing this bug to light SuperMario, I will wait to get a TS-1079 Pro until this bug is found and fixed since I will be using 3 Tb drives and will likely surpass the problem usage parameters quickly.

[q20]

FYI, Anandtech recently reviewed the TS-659 Pro II. They've now been made aware of this bug and are stress testing to see if they're able to reproduce it. Their review will be amended if necessary.

SuperMario, if you can be of assistance, leave a comment for Ganesh here:

http://www.anandtech.com/show/4834/qnap-ts659-pro-ii-review?all=true

If you want one tech site on your side, it's Anandtech.

[Mako_77]

Hi,

I'm also noticing a slow down. Thou I have about 40% space left. I have almost no services running apart from the TCP, AD and using it as a samba server for file backups. Everything else is switched off where it can be. I noticed a major drop in speed when I went from 3.3 to 3.4 firmware.

My old SnapServer is significantly quicker than this box running on a old PIII processor. I am suprised QNAP haven't found the problem yet let alone fix it......

Ed

[rancid-lemon]

Looks like this thread is gaining some traction now. I am holding off on a purchase due to this issue.
Please could a QNAP representative supply some concrete information on the problem and an ETA to a solution. Assuming that a solution is possible?!

rancid

[sh4d0wt3ch]

Thread is now definitely alive. I have opened several threads about this but no one seemed to pick it up, I was pointed to this thread by Mario and been posting on this thread eversince.

[SuperMario]

Hello all,

I have had an email exchange with Anand and Ganesh earlier in the week, so I hope they can shed more like on this issue. I believe that they are doing the right thing by trying to replicate the issue for themselves.

Seeing we have a total of 7 QNAPs that all exhibit this issue to various extents, I don't think the issue is too hard to bring about, it's demonstrably with the file/directory load on the volume and the newer FW versions.

I'm also performing various test as and when requested by QNAP in the background. I just hope that this can be resolved soon as I fear that both of the TS-6x9 (previously our backup) units we are now using as the main servers are starting to worry us.

We're also at the point where we have extracted ~7.4 TB of our data from TS-859's corrupted volume, but I now think that's all we'll manage to get from it - but that is better than nothing. I think I said earlier that we believe the corruption was caused by the automated rebuild of the RAID after a spurious drive eject and reboot, it appears the rebuild writes pushed the volume over the edge. If you have this issue, don't allow any writes to the unit and back what you can up... if you get to the point a drive is dropped or it reboots, the RAID reconstruction starts automatically.

I'm now waiting for a new box of HDD's from Seagate to be delivered and then we'll rebuild the TS-859Pro volume from scratch and then try to put everything back, until we can find the exact point the problems start to occur, but my time is limited after spending the past week or so on pulling data off the corrupted volume.

Mario.

[some1else]

i guess you can add me to the list aswell.
have been struggeling with this for quite some time now!

I have two Qnap's, one TS-439Pro (who's acting as it should) and a TS-659 Pro whos stuck at 6,97%

See topic: viewtopic.php?f=185&t=44112&p=197460#p195076
Have tried to replace the HDD's without any luck. Hope we'll get a fix soon!!

[junitrules]

Bought a new TS-210. Upgraded it to the latest firmware (3.5.0 Build0816) and tested out the file transfer speed - 2.45MB/S when transferring to, and from the QNAP...

I have 2x 1TB Samsung HDDs in the box which were empty (other than EXT4 info). Have tried plugging the PC directly into the QNAP and still slow...

My question is, is this slow speed down to the firmware issue detailed in this thread? I have searched through the forum for answers but only come across this one...

Thanks in advance.

J

[P3R]

I have 2x 1TB Samsung HDDs in the box which were empty (other than EXT4 info). Have tried plugging the PC directly into the QNAP and still slow...

My question is, is this slow speed down to the firmware issue detailed in this thread?

The problem in this thread isn't properly diagnosed yet but most things indicate that it has something to do with the data volume being pretty well filled up so I'd guess that your issue is different.

I have searched through the forum for answers but only come across this one...

I've read about new users being disappointed about slow performance many times. The most common issue being that the unit is still synchronizing the data volume, which slows it down.

Performance should be different when writing to and reading from the NAS so if you have exactly the same speed that could be an indication that you have a different bottleneck from what normally limits performance (the NAS CPU).

If you can't find another thread that fits, start your own and explain a bit more detailed about what you have and what you've done so far. These following are the first things I come to think of right now that could be important in your troubleshooting:

• Exactly what model of Samsung 1 TB disks are being used?
• What disk configuration is being used and has it finished synchronizing (if relevant depending on the previous answer)?
• Have you tried rebooting?
• Any errors reported on the disks?
• What services and applications are enabled in the Qnap?
• Have you verified what connection speed the network interface gets?
• What category network cable is being used, have you tried a different one or verified it being okay elsewhere?
• Have you checked the network error counter?
• What PC is being used with what OS?
• Any antivirus software or anything else slowing the PC down?
• Have you verified the PC can perform better against something else.
• What protocol is being used for the communication?
• What did you copy (one gigabyte file or a million kilobyte files)?
• How did you measure the performance?

[AlexKe]

Bought a new TS-210. Upgraded it to the latest firmware (3.5.0 Build0816) and tested out the file transfer speed - 2.45MB/S when transferring to, and from the QNAP...

I have 2x 1TB Samsung HDDs in the box which were empty (other than EXT4 info). Have tried plugging the PC directly into the QNAP and still slow...

My question is, is this slow speed down to the firmware issue detailed in this thread? I have searched through the forum for answers but only come across this one...

Thanks in advance.

J

@ junitrules

Please check the following condition if you encounter the slow performance issue. Normally, the bottleneck is at the client PC performance. There is difference between transfer a single large file and a large amount of small files (the latter one will be slower).

- Check the HDD RPM on both NAS and client PC (7200 RPM will be advised for performance )
- Client PC performance (CPU, Memory, )
- Network switch 10/100 MB/s or 1000 MB/s (10 MB/s under 100 MB/s network environment)
- Using network cable Cat5e or Cat6
- Disable the firewall or antivirus scan on the client PC
- Go to NAS [System Information] > [Port Status], and check the "Error Packets"
(It can be hardware issue on PC or NAS if there are many error packets occurred.)

[QNAPSimon]

For those who hasn't already done so. Please turn off all the other services except for the ones that you are using to transfer files, smb, nfs, etc.... and reboot your NAS. This is only to make sure we don't have different services interfering and localize the real problem. Please PM me if you still have problem transferring files afterwards. We will go over further testing procedures.

Thanks

[AdrianW]

For those who hasn't already done so. Please turn off all the other services except for the ones that you are using to transfer files, smb, nfs, etc.... and reboot your NAS. This is only to make sure we don't have different services interfering and localize the real problem. Please PM me if you still have problem transferring files afterwards. We will go over further testing procedures.

Thanks

I've just got home and I've disabled everything except samba - and I'm still getting the 40 second stall.

[Mako_77]

Hi,

I'm might have misread this wrong but??? surely that should have been done when this problem was first reported back in version 3.4 ?? As stated in my post above in this thread (and a seperate thread which no-one has responded too), I'm running on minimal services (infact I only use the QNAP for samba transfer, don't use the other features at all).

Could QNAP give an official response as to why this is not a prioirty bug and if it is why this is taking so long to identify, considering everyone can recreate it?????

Thanks

Ed

[Ganesh_AnandTech]

SuperMario, Thanks for bringing this issue to my attention. Simon from QNAP has already responded in the comments section of the review. However, that doesn't mean I have stopped trying to recreate the bug.

First off, I tried with the supplied 6 x 1 TB Samsung drives in RAID6, and got the unit to around 80% full with ~20 K files and ~5K folders (files varying in size between 30 KB and 5 GB). However, that didn't replicate the issue reported here.

I have since shifted to 6 x 2 TB Seagate drives in RAID 5 and started the script to fill up the NAS (It is around 50% full right now with ~60K files and ~10K folders, but the issue hasn't shown up yet). I believe the key here is issue reproducibility, i.e, given a list of operations to do on the SAMBA share, anyone should be able to replicate the issue. Towards that, can users with the issue let me in on the following information?:

1. Number of files and folders in the system with the issue

2. File size distribution (can be generated with something like JDiskReport)

3. How long after using the unit did the user start experiencing the issues?

The script I am using to fill up the NAS is currently running in fill mode (randomly creating folders and files of varying sizes according to a predefined file size distribution). I can tweak it to run in transaction mode (wherein files / folders are also deleted at random during the fill process). Did the real world units with the issues experience lots of file / folder deletions as well?