grocovid wrote:What I'm thinking here is that some of us are transferring their frustration of running out of disk space on a fauly NAS software (and again, it IS annoying, it shouldn't take so long, ... - I agree with you guys), since we run out of space sooner than we expected. When choosing my new NAS, I compared with the competition - correcting for the fact that with QNAP I will only be able to use 90% of my disk space - and still QNAP is the best deal.
grocovid wrote:When the problem occurs, it certainly causes loss of performance and functionality. But I've yet find a reasonable explanation on how it can cause data corruption or loss. It seems to be something users post to scare QNAP.
heroheroz wrote:I suggest to people who suffer from the same problem simply find a few review forums and put the fact there, the only way to make them care is let their potential customer know about it and make qnap lose their business.
BloodShed wrote:... You should also have noticed that the originally reported usage percentage at which failure occurs is 75%; not 90%. ...
grocovid wrote:Come on, BloodShed, I'm not interested in name-calling
grocovid wrote:Please review this thread carefully, and you will see that I'm one of those people who posted repeated observations, possible hypotheses (including fragmentation issues), new remarks (like the fact that when a 700 MB file is deleted under the "freezing" condition and you try to reuse that same place immediately afterwards, this space can be reused without any freeze).
grocovid wrote:And I think I know this bug, I've been using my NAS in this terrible condition for months, copying files at 50 KB/sec on a gigabit line, without any corruption, ever (ext4, no write cache).
grocovid wrote:Saying that I did not read this thread carefully is dishonest;
grocovid wrote:You may disagree with me. But I've yet to find evidence of data loss caused by this issue.
grocovid wrote:I'm saying that, in MY experience (and, again, there may be different configurations, and differing severities for this bug), it happens around 90-95% (for 6 - 9 TB total capacity) and is a pain in the ** but doesn't cause data loss. In MY experience, freeing up disk space makes it more easy to reuse than the first time it was used (strange, but true and reproducible).
grocovid wrote:It seems to be something users post to scare QNAP.
grocovid wrote:Moreover, I've been carefully comparing prices in my country, for equivalents to the TS-412, and even removing 25% capacity, Synos are more expensive.
But most likely that is unrelated to the bug in this thread.Flerbizky wrote:Steffen - Left with an empty partition table :-/
BloodShed wrote:Again, if you had followed the thread, supermario had reported data loss as a result of this issue. Was it related? I can't say for sure.
BloodShed wrote:grocovid wrote:Moreover, I've been carefully comparing prices in my country, for equivalents to the TS-412, and even removing 25% capacity, Synos are more expensive.
I don't think you understood the point I was making. Comparing prices in your specific country, for your specific hardware does not directly correlate to anyone else. It's no secret that QNAP supplies multiple products worldwide. More importantly, you can not remove "25% capacity" on the value of a device that does not ship with hard drives. Last, it doesn't matter if you want to apply a loss of 10%, 25%, or whatever number you want to switch your figures to. There is no percentage at which this problem occurs. Therefore, your claim that "QNAP is the best deal" is invalid and absurd.
BloodShed wrote:My problem is that I don't appreciate someone jumping into the middle of this exhausting discussion with misinformation and praise for QNAP. As I've said before, my patience is at its limit on this.
BloodShed wrote:QNAP has shown no real evidence that they have done any work on this issue or that they even care to prioritize it. Because you skipped the majority of this thread, I'll catch you up... QNAP has already claimed (in this very thread) that they had recreated the problem and they're working on a fix, only to come back later to clarify that they never actually recreated it at all. So I've quickly learned that, until I see a fix, I can't trust a single thing QNAP says.
sl1000 wrote:As QNAP has added some modifications in firmware 3.7.0/3.7.1 which should fix this issue, i've unlocked this thread again.
Fixed the slow write speed when the system would take a long time to find free blocks with large amount of data stored on the NAS
Users browsing this forum: jonnyg69 and 2 guests