Date: Wed, 14 Aug 2019 17:49:25 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 238663] [UFS] Corrupted files since migration to FreeBSD11 Message-ID: <bug-238663-3630-j4k0VxQ7jz@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-238663-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-238663-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238663 --- Comment #10 from Kirk McKusick <mckusick@FreeBSD.org> --- (In reply to Masse Nicolas from comment #9) I was going to suggest that you try disabling TRIM on your disk to see if t= hat helped solve the problem. Some folks that I am working with at Netflix have found some rather severe bugs in TRIM support on some of the flash drives t= hat they have been using. I have bought an array of cheap flash drives on Amazon and tried them out u= sing your suggested tests. I have not been able to precisely reproduce your problems, but I have gotten problems that are caused by what appears to be faulty TRIM implementations (i.e., the problem goes away when I disable TRI= M). Is the drive on which you are experiencing the problem a flash drive, and i= f so does the problem go away when you disable TRIM? If so, then I would chalk up the problem to faulty TRIM microcode. I added TRIM consolidation in -r338517 which helps reduce the number of TRIM commands sent to the drive by aggregating them into bigger pieces. But the bigger pieces can hit other TRIM bugs that do not deal well with big TRIM requests. So you can try disabling vfs.ffs.dotrimcons to see if that makes a difference. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-238663-3630-j4k0VxQ7jz>