Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 05 Jul 2017 14:03:12 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-fs@FreeBSD.org
Subject:   [Bug 220203] [zfs] [panic] in dmu_objset_do_userquota_updates on mount
Message-ID:  <bug-220203-3630-fRSuNqNvnj@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-220203-3630@https.bugs.freebsd.org/bugzilla/>
References:  <bug-220203-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=3D220203

--- Comment #6 from neovortex@gmail.com ---
So since moving the SSDs from the SAS2008 controller to the mainboard SATA
controller this issue hasn't reoccurred again. Considering the frequency it=
 was
reoccurring previously, I'd say that's done the trick.

I guess this issue really has two parts, one is what's causing corruption w=
ith
SSDs on the SAS2008 controller (my guess being TRIM related), bug in FreeBS=
D,
bug in SAS2008 firmware, or bug in SSD firmware that only gets triggered wh=
en
on a SAS2008 controller, but not on other controllers.

For completeness, the SSDs are the following:

=3D=3D=3D START OF INFORMATION SECTION =3D=3D=3D
Model Family:     Marvell based SanDisk SSDs
Device Model:     SanDisk SDSSDHII480G
Serial Number:    xxx
LU WWN Device Id: xxx
Firmware Version: X31200RL
User Capacity:    480,103,981,056 bytes [480 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2 T13/2015-D revision 3
SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Wed Jul  5 23:56:36 2017 EST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=3D=3D=3D START OF READ SMART DATA SECTION =3D=3D=3D

The second issue I guess is when a filesystem has corrupt metadata if it co=
uld
be handled more gracefully, eg zfs mount returns an error rather than causi=
ng a
panic. I'm not sure how practical this is, but it was an unusual experience
having on-disk corruption causing a panic compared to the behaviour of other
filesystems.

--=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-220203-3630-fRSuNqNvnj>