Date: Thu, 4 Jan 2018 19:52:19 +0100 From: Michael Tuexen <tuexen@freebsd.org> To: "O. Hartmann" <ohartmann@walstatt.org> Cc: Warner Losh <imp@bsdimp.com>, FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2> Message-ID: <6C2F2C0A-D075-4DF1-88E3-64CE31E016F9@freebsd.org> In-Reply-To: <20180104121447.4d9109ed@freyja.zeit4.iv.bundesimmobilien.de> References: <20171231004137.4f9ad496@thor.intern.walstatt.dynvpn.de> <CANCZdfoMdgCrAAXadc-G6v1r0wA-qv=Ms_XKYPd7cFqSc5%2B9GQ@mail.gmail.com> <23651B78-E31C-4BDD-BCA3-408B8F907884@freebsd.org> <20180104121447.4d9109ed@freyja.zeit4.iv.bundesimmobilien.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 4. Jan 2018, at 12:14, O. Hartmann <ohartmann@walstatt.org> wrote: > > On Thu, 4 Jan 2018 09:10:37 +0100 > Michael Tuexen <tuexen@freebsd.org> wrote: > >>> On 31. Dec 2017, at 02:45, Warner Losh <imp@bsdimp.com> wrote: >>> >>> On Sat, Dec 30, 2017 at 4:41 PM, O. Hartmann <ohartmann@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. >> Not sure this helps: But we have seen this also after system panics >> when having soft update journaling enabled. Having soft update journaling >> disabled, we do not observed this after several panics. >> Just to be clear: The panics are not related to this issue, >> but to other network development we do. >> >> You can check using tunefs -p devname if soft update journaling is enabled or >> not. > > 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). OK. That seems to be consistent. Here is the config I'm using on m-SATA SSDs and I'm NOT experiencing the problem: tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) disabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) enabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: space to hold for metadata blocks: (-k) 6408 tunefs: optimization preference: (-o) time tunefs: volume label: (-L) This was the config I was experiencing the problem: tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled tunefs: trim: (-t) enabled tunefs: maximum blocks per file in a cylinder group: (-e) 4096 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: space to hold for metadata blocks: (-k) 6408 tunefs: optimization preference: (-o) time tunefs: volume label: (-L) So "soft updates" are enabled on both configs, but "soft update journaling" is different. Maybe this helps in nailing down the problem. Best regards Michael > >> >> Best regards >> Michael >>> >>> Warner >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6C2F2C0A-D075-4DF1-88E3-64CE31E016F9>