r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2>

[Warner Losh]

On Sat, Dec 30, 2017 at 4:41 PM, O. Hartmann <ohartmann at walstatt.org> wrote:

> On most recent CURRENT I face the error shwon below on /tmp filesystem
> (UFS2) residing
> on a Samsung 850 Pro SSD:
>
> UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3 !=
> bp: 0xd9fba319
>  handle_workitem_freefile: got error 5 while accessing filesystem
>  UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3
> != bp: 0xd9fba319
>  handle_workitem_freefile: got error 5 while accessing filesystem
>  UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3
> != bp: 0xd9fba319
>  handle_workitem_freefile: got error 5 while accessing filesystem
>  UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3
> != bp: 0xd9fba319
>  handle_workitem_freefile: got error 5 while accessing filesystem
>  UFS /dev/gpt/tmp (/tmp) cylinder checksum failed: cg 0, cgp: 0x4515d2a3
> != bp: 0xd9fba319
>  handle_workitem_freefile: got error 5 while accessing filesystem
>
> I've already formatted the /tmp filesystem, but obviously without any
> success.
>
> Since I face such strange errors also on NanoBSD images dd'ed to SD cards,
> I guess there
> is something fishy ...


It indicates a problem. We've seen these 'corruptions' on data in motion 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 fsck the
filesystem.

Warner