https://bugzilla.kernel.org/show_bug.cgi?id=219300 --- Comment #7 from nxe9 (linuxnormaluser@xxxxxxxxx) --- Thank you for your entries. My pendrive is not a Chinese fake and I think size is not correct. At least that's what I think. Intenso is a German company, although the chips are probably imported from the Far East. Back to the topic... I don't know much about file systems, so I'm relying on you. Is it likely that the file systems are so different that a hardware bug is visible regularly on one file system but is impossible to reproduce on the other? Besides, the fact is that two pendrives of the same model have the problem, and other models, even from the same manufacturer, do not. If I could see the error on ntfs just once, I wouldn't have a problem, but so far I haven't been able to reproduce the error on ntfs even once. Today I tested ntfs again with f3 and as usual no error. Apart from that I generated test data and filled the disk completely. As usual, all fully consistent on ntfs. Freespace on ext4 according to f3write: Free space: 28.67 GB Freespace on ntfs according to f3write: Free space: 29.23 GB As you can see, I can write even more data to ntfs and it will not generate errors. I will summarize some points: - i/o errors in dmesg appear very rarely. During data corruption this error usually does not appear. - f3 tests on ext4 are negative only sometimes. - when copying my own files to ext4 I can generate data inconsistency very quickly. - badblocks doesn't show me any errors. - ntfs always works great Therefore, I am still interested in whether one file system can actually hide hardware defects (or is implemented in such a way that it is very difficult to reproduce) or maybe the other file system has some rare bug that will only become visible in the case of this hardware. For me it's not settled. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
