[Bug 220203] [zfs] [panic] in dmu_objset_do_userquota_updates on mount

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Wed Jul 5 14:03:12 UTC 2017


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220203

--- Comment #6 from neovortex at 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 with
SSDs on the SAS2008 controller (my guess being TRIM related), bug in FreeBSD,
bug in SAS2008 firmware, or bug in SSD firmware that only gets triggered when
on a SAS2008 controller, but not on other controllers.

For completeness, the SSDs are the following:

=== START OF INFORMATION SECTION ===
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

=== START OF READ SMART DATA SECTION ===

The second issue I guess is when a filesystem has corrupt metadata if it could
be handled more gracefully, eg zfs mount returns an error rather than causing 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-fs mailing list