Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 07 Jan 2018 16:24:36 -0800
From:      "Chris H" <bsd-lists@BSDforge.com>
To:        "O. Hartmann" <ohartmann@walstatt.org>
Cc:        "Michael Tuexen" <tuexen@freebsd.org>, "Warner Losh" <imp@bsdimp.com>, "FreeBSD CURRENT" <freebsd-current@freebsd.org>, "O. Hartmann" <ohartmann@walstatt.org>
Subject:   Re: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2>
Message-ID:  <f74c93401bb2bd01fb730f9e5f5ee3f2@udns.ultimatedns.net>
In-Reply-To: <20180107123201.19ea0fde@thor.intern.walstatt.dynvpn.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 7 Jan 2018 12:31:34 +0100 "O=2E Hartmann" <ohartmann@walstatt=2Eorg> sa=
id

> Am Thu, 4 Jan 2018 12:14:47 +0100
> "O=2E Hartmann" <ohartmann@walstatt=2Eorg> schrieb:
>=20
> > On Thu, 4 Jan 2018 09:10:37 +0100
> > Michael Tuexen <tuexen@freebsd=2Eorg> wrote:
> >=20
> > > > On 31=2E Dec 2017, at 02:45, Warner Losh <imp@bsdimp=2Ecom> wrote:
> > > >=20
> > > > On Sat, Dec 30, 2017 at 4:41 PM, O=2E Hartmann <ohartmann@walstatt=2Eor=
g>
> > wrote:
> > > >    =20
> > > >> On most recent CURRENT I face the error shwon below on /tmp filesy=
stem
> > > >> (UFS2) residing
> > > >> on a Samsung 850 Pro SSD:
> > > >>=20
> > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x451=
5d2a3
> > !=3D
> > > >> bp: 0xd9fba319
> > > >> handle_workitem_freefile: got error 5 while accessing filesystem
> > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x451=
5d2a3
> > > >> !=3D bp: 0xd9fba319
> > > >> handle_workitem_freefile: got error 5 while accessing filesystem
> > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x451=
5d2a3
> > > >> !=3D bp: 0xd9fba319
> > > >> handle_workitem_freefile: got error 5 while accessing filesystem
> > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x451=
5d2a3
> > > >> !=3D bp: 0xd9fba319
> > > >> handle_workitem_freefile: got error 5 while accessing filesystem
> > > >> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x451=
5d2a3
> > > >> !=3D bp: 0xd9fba319
> > > >> handle_workitem_freefile: got error 5 while accessing filesystem
> > > >>=20
> > > >> I've already formatted the /tmp filesystem, but obviously without =
any
> > > >> success=2E
> > > >>=20
> > > >> Since I face such strange errors also on NanoBSD images dd'ed to S=
D
> > cards,
> > > >> I guess there
> > > >> is something fishy =2E=2E=2E   =20
> > > >=20
> > > >=20
> > > > It indicates a problem=2E We've seen these 'corruptions' on data in m=
otion
> > at
> > > > work, but I hacked fsck to report checksum mismatches (it silently
> > corrects
> > > > them today) and we've not seen any mismatch when we unmount and fsc=
k the
> > > > filesystem=2E   =20
> > > Not sure this helps: But we have seen this also after system panics
> > > when having soft update journaling enabled=2E Having soft update journa=
ling
> > > disabled, we do not observed this after several panics=2E
> > > Just to be clear: The panics are not related to this issue,
> > > but to other network development we do=2E
> > >=20
> > > You can check using tunefs -p devname if soft update journaling is en=
abled
> > or
> > > not=2E =20
> >=20
> > In all cases I reported in earlier and now, softupdates ARE ENABLED on =
all
> > partitions in question (always GPT, in my cases also all on flash based
> > devices, SD card and/or SSD)=2E
>=20
>=20
> =2E=2E=2E and journalling as well!
>=20
> In case of the SD, I produced the layout of the NanoBSD image via "dd"
> including the /cfg
> partition=2E The problem occured even when having overwritten the SD card w=
ith
> a new image=2E
> The problem went away once I unmounted /cfg and reformatted via newfs=2E Af=
ter
> that, I did
> not see any faults again! I have no explanation for this behaviour except=
 the
> dd didn't
> overwrite "faulty" areas or the obligate "gpart recover" at the end of th=
e
> procedure
> restored something faulty=2E
>=20
> The /tmp filesystem I reported in was also from an earlier date - and I
> didn't formatted
> it as I said - I confused the partition in question with another one=2E The
> partition has
> been created and formatted months ago under CURRENT=2E
>=20
> In single user mode, I reformatted the partition again - with journaling =
and
> softupdates
> enabled=2E As with the /cfg partition on NanoBSD with SD card, I didn't rea=
lise
> any faults
> again since then=2E=20
FWIW I *also* experience this on gpart/FFS2 partitioned/formatted drives
*with* journaling enabled=2E As a result; if the system crashes, more often
times, than not, fsck(8) canNOT use the journal, and indicates that it
must "fall through" to complete the task=2E This is on a SATA (ahci) driven
disk=2E My experiences with this seem to suggest that journaling is the cause=
=2E

>=20
> >=20
> >=20
> > >=20
> > > Best regards
> > > Michael =20
> > > >=20
> > > > Warner
> --=20
> O=2E Hartmann
>=20
> Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=
=BCr
> Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Ab=
s=2E 4 BDSG)=2E

--Chris





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f74c93401bb2bd01fb730f9e5f5ee3f2>