Skip site navigation (1)Skip section navigation (2)
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>