Re: fsck strange output
> From: Rozhuk Ivan
> Date: Tue, 26 Jan 2021 17:08:41 +0300
> To: Kirk McKusick
> Cc: freebsd-current@freebsd.org
> Subject: Re: fsck strange output
>
> On Mon, 25 Jan 2021 15:40:12 -0800
> Kirk McKusick wrote:
>
>
>> Please try this patch to fsck_ffs and see if it fixes your problem.
>>
>> Kirk McKusick
>>
>> =-=-=
>>
>> *** sbin/fsck_ffs/inode.c.orig 2021-01-07 15:04:04.969086284
>> -0800 --- sbin/fsck_ffs/inode.c 2021-01-25 15:29:06.404803358
>> -0800 ***
>> *** 611,618
>> sizeof(struct ufs1_dinode) : sizeof(struct
>> ufs2_dinode)); readpercg = inosused / fullcnt;
>> partialcnt = inosused % fullcnt;
>> !partialsize = partialcnt * ((sblock.fs_magic ==
>> FS_UFS1_MAGIC) ? ! sizeof(struct ufs1_dinode) :
>> sizeof(struct ufs2_dinode)); if (partialcnt != 0) {
>> readpercg++;
>> } else {
>> --- 611,619
>> sizeof(struct ufs1_dinode) : sizeof(struct
>> ufs2_dinode)); readpercg = inosused / fullcnt;
>> partialcnt = inosused % fullcnt;
>> !partialsize = fragroundup(,
>> !partialcnt * ((sblock.fs_magic == FS_UFS1_MAGIC) ?
>> !sizeof(struct ufs1_dinode) : sizeof(struct
>> ufs2_dinode))); if (partialcnt != 0) {
>> readpercg++;
>> } else {
>
>
> https://github.com/rozhuk-im/freebsd/commit/5e8bfa01830e2b6ecb88e572064c6fffe5a2df2d
> (if I apply correct :) )
>
> With this patch - seems no errors, thanks!
Thanks for your testing. It has also corrected the same problem in
Peter Holm's test suite. So, I am committed it as 8c22cf9. I will
also ensure that it gets MFC'ed into 13.0.
Kirk McKusick
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: fsck strange output
On Mon, 25 Jan 2021 15:40:12 -0800
Kirk McKusick wrote:
> Please try this patch to fsck_ffs and see if it fixes your problem.
>
> Kirk McKusick
>
> =-=-=
>
> *** sbin/fsck_ffs/inode.c.orig2021-01-07 15:04:04.969086284
> -0800 --- sbin/fsck_ffs/inode.c 2021-01-25 15:29:06.404803358
> -0800 ***
> *** 611,618
> sizeof(struct ufs1_dinode) : sizeof(struct
> ufs2_dinode)); readpercg = inosused / fullcnt;
> partialcnt = inosused % fullcnt;
> ! partialsize = partialcnt * ((sblock.fs_magic ==
> FS_UFS1_MAGIC) ? !sizeof(struct ufs1_dinode) :
> sizeof(struct ufs2_dinode)); if (partialcnt != 0) {
> readpercg++;
> } else {
> --- 611,619
> sizeof(struct ufs1_dinode) : sizeof(struct
> ufs2_dinode)); readpercg = inosused / fullcnt;
> partialcnt = inosused % fullcnt;
> ! partialsize = fragroundup(,
> ! partialcnt * ((sblock.fs_magic == FS_UFS1_MAGIC) ?
> ! sizeof(struct ufs1_dinode) : sizeof(struct
> ufs2_dinode))); if (partialcnt != 0) {
> readpercg++;
> } else {
https://github.com/rozhuk-im/freebsd/commit/5e8bfa01830e2b6ecb88e572064c6fffe5a2df2d
(if I apply correct :) )
With this patch - seems no errors, thanks!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: fsck strange output
> > > Rozhuk Ivan writes: > > > Disk is 100% alive, got same on other HW. > > A disk can be alive and still have individually unreadable sectors, > that is, IMO, the most common failure mode. > > Try: > recoverdisk -v /dev/whatever > > That will attempt to read all sectors on the disk. > It's possible fisical crash. You can try a fsck -f And after try smarttools ( in ports ) to check a health of S.M.A.R.T IHMO. > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: fsck strange output
Rozhuk Ivan rozhuk.im at gmail.com wrote on Tue Jan 26 00:58:07 UTC 2021 : > This happen on 4 different systems, that: > - based on Ryzen zen/zen+ > - FreeBSD 13 > > 2 systems have ECC that works and show no errors. This is just a example-contexts note: I've seen what appears to be the same type of "UNEXPECTED SOFT UPDATE INCONSISTENCY" issue on an old 2-socket/2-cores-each PowerMac G5 powerpc64 configuration that was running main from after 5cc52631b3b8 . So, in this case, I do not expect that the problem is special to Ryzen or related CPUs. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: fsck strange output
On Mon, 25 Jan 2021 20:51:50 + "Poul-Henning Kamp" wrote: > > Disk is 100% alive, got same on other HW. > > A disk can be alive and still have individually unreadable sectors, > that is, IMO, the most common failure mode. > > Try: > recoverdisk -v /dev/whatever > > That will attempt to read all sectors on the disk. > This happen on 4 different systems, that: - based on Ryzen zen/zen+ - FreeBSD 13 2 systems have ECC that works and show no errors. At least on 12 and prev on read error - kernel show messages from drivers/geom. recoverdisk -v - show no error. I can reproduce this in VBox after disable "soft update journaling". (I hope that you will not require from me to check VBox HW too :) ) VBOx - no "CANNOT READ BLK": # tunefs -p /dev/ada0p2 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) disabled 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) 2% tunefs: space to hold for metadata blocks: (-k)1600 tunefs: optimization preference: (-o) space tunefs: volume label: (-L) VBOx - "CANNOT READ BLK" is present: # tunefs -p /dev/ada0p2 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) disabled 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) 2% tunefs: space to hold for metadata blocks: (-k)1600 tunefs: optimization preference: (-o) space tunefs: volume label: (-L) 5cc52631b3b88dfc36d8049dc8bece8573c5f9af [PATCH] Rewrite the disk I/O management system in fsck_ffs(8). Other Since this commit this issue started. I check: build system from prev commit - OK, build from this - "CANNOT READ BLK". ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: fsck strange output
> From: Rozhuk Ivan
> Date: Mon, 25 Jan 2021 23:29:33 +0300
> To: freebsd-current@freebsd.org
> Cc: Rozhuk Ivan
> Subject: fsck strange output
>
> Hi!
>
> I am on fresh 13 and on auto fsck got:
>
> Jan 25 23:14:13 3des kernel: Starting file system checks:
> Jan 25 23:14:13 3des kernel: /dev/gptid/81241708-8948-11e9-b1ae-049226c061d6:
> CANNOT READ BLK: 11072
> Jan 25 23:14:13 3des kernel: /dev/gptid/81241708-8948-11e9-b1ae-049226c061d6:
> UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY.
> Jan 25 23:14:13 3des kernel: File system preen failed, trying fsck -y -T
> ffs:-R,-r -T ufs:-R,-r
> Jan 25 23:14:13 3des kernel: **
> /dev/gptid/81241708-8948-11e9-b1ae-049226c061d6
> Jan 25 23:14:13 3des kernel: ** Last Mounted on /
> Jan 25 23:14:13 3des kernel: ** Root file system
> Jan 25 23:14:13 3des kernel: ** Phase 1 - Check Blocks and Sizes
> Jan 25 23:14:13 3des kernel:
> Jan 25 23:14:13 3des kernel: CANNOT READ BLK: 11072
> Jan 25 23:14:13 3des kernel: UNEXPECTED SOFT UPDATE INCONSISTENCY
> Jan 25 23:14:13 3des kernel:
> Jan 25 23:14:13 3des kernel: CONTINUE? yes
> Jan 25 23:14:13 3des kernel:
> Jan 25 23:14:13 3des kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> Jan 25 23:14:13 3des kernel:
> Jan 25 23:14:13 3des kernel: CANNOT READ BLK: 5129280
> Jan 25 23:14:13 3des kernel: UNEXPECTED SOFT UPDATE INCONSISTENCY
> Jan 25 23:14:13 3des kernel:
> Jan 25 23:14:13 3des kernel: CONTINUE? yes
> Jan 25 23:14:13 3des kernel:
> Jan 25 23:14:13 3des kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> Jan 25 23:14:13 3des kernel:
> Jan 25 23:14:13 3des kernel: CANNOT READ BLK: 6411520
> Jan 25 23:14:13 3des kernel: UNEXPECTED SOFT UPDATE INCONSISTENCY
> Jan 25 23:14:13 3des kernel:
> Jan 25 23:14:13 3des kernel: CONTINUE? yes
> Jan 25 23:14:13 3des kernel:
> Jan 25 23:14:13 3des kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> Jan 25 23:14:13 3des kernel:
> Jan 25 23:14:13 3des kernel: CANNOT READ BLK: 7693888
> Jan 25 23:14:13 3des kernel: UNEXPECTED SOFT UPDATE INCONSISTENCY
> Jan 25 23:14:13 3des kernel:
> Jan 25 23:14:13 3des kernel: CONTINUE? yes
>
>
> Disk is 100% alive, got same on other HW.
> fsck -y - have no this strange problem with reading.
>
> Is it OK "CANNOT READ BLK ..." ?
>
>
> >From my rc.conf:
> fsck_y_enable="YES" # Set to YES to do fsck -y if the initial preen
> fails.
> fsck_y_flags="-T ffs:-R,-r -T ufs:-R,-r" # Additional flags for fsck -y
> background_fsck="NO" # Attempt to run fsck in the background where
> possible.
Please try this patch to fsck_ffs and see if it fixes your problem.
Kirk McKusick
=-=-=
*** sbin/fsck_ffs/inode.c.orig 2021-01-07 15:04:04.969086284 -0800
--- sbin/fsck_ffs/inode.c 2021-01-25 15:29:06.404803358 -0800
***
*** 611,618
sizeof(struct ufs1_dinode) : sizeof(struct ufs2_dinode));
readpercg = inosused / fullcnt;
partialcnt = inosused % fullcnt;
! partialsize = partialcnt * ((sblock.fs_magic == FS_UFS1_MAGIC) ?
! sizeof(struct ufs1_dinode) : sizeof(struct ufs2_dinode));
if (partialcnt != 0) {
readpercg++;
} else {
--- 611,619
sizeof(struct ufs1_dinode) : sizeof(struct ufs2_dinode));
readpercg = inosused / fullcnt;
partialcnt = inosused % fullcnt;
! partialsize = fragroundup(,
! partialcnt * ((sblock.fs_magic == FS_UFS1_MAGIC) ?
! sizeof(struct ufs1_dinode) : sizeof(struct ufs2_dinode)));
if (partialcnt != 0) {
readpercg++;
} else {
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: fsck strange output
Rozhuk Ivan writes: > Disk is 100% alive, got same on other HW. A disk can be alive and still have individually unreadable sectors, that is, IMO, the most common failure mode. Try: recoverdisk -v /dev/whatever That will attempt to read all sectors on the disk. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
fsck strange output
Hi! I am on fresh 13 and on auto fsck got: Jan 25 23:14:13 3des kernel: Starting file system checks: Jan 25 23:14:13 3des kernel: /dev/gptid/81241708-8948-11e9-b1ae-049226c061d6: CANNOT READ BLK: 11072 Jan 25 23:14:13 3des kernel: /dev/gptid/81241708-8948-11e9-b1ae-049226c061d6: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY. Jan 25 23:14:13 3des kernel: File system preen failed, trying fsck -y -T ffs:-R,-r -T ufs:-R,-r Jan 25 23:14:13 3des kernel: ** /dev/gptid/81241708-8948-11e9-b1ae-049226c061d6 Jan 25 23:14:13 3des kernel: ** Last Mounted on / Jan 25 23:14:13 3des kernel: ** Root file system Jan 25 23:14:13 3des kernel: ** Phase 1 - Check Blocks and Sizes Jan 25 23:14:13 3des kernel: Jan 25 23:14:13 3des kernel: CANNOT READ BLK: 11072 Jan 25 23:14:13 3des kernel: UNEXPECTED SOFT UPDATE INCONSISTENCY Jan 25 23:14:13 3des kernel: Jan 25 23:14:13 3des kernel: CONTINUE? yes Jan 25 23:14:13 3des kernel: Jan 25 23:14:13 3des kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ: Jan 25 23:14:13 3des kernel: Jan 25 23:14:13 3des kernel: CANNOT READ BLK: 5129280 Jan 25 23:14:13 3des kernel: UNEXPECTED SOFT UPDATE INCONSISTENCY Jan 25 23:14:13 3des kernel: Jan 25 23:14:13 3des kernel: CONTINUE? yes Jan 25 23:14:13 3des kernel: Jan 25 23:14:13 3des kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ: Jan 25 23:14:13 3des kernel: Jan 25 23:14:13 3des kernel: CANNOT READ BLK: 6411520 Jan 25 23:14:13 3des kernel: UNEXPECTED SOFT UPDATE INCONSISTENCY Jan 25 23:14:13 3des kernel: Jan 25 23:14:13 3des kernel: CONTINUE? yes Jan 25 23:14:13 3des kernel: Jan 25 23:14:13 3des kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ: Jan 25 23:14:13 3des kernel: Jan 25 23:14:13 3des kernel: CANNOT READ BLK: 7693888 Jan 25 23:14:13 3des kernel: UNEXPECTED SOFT UPDATE INCONSISTENCY Jan 25 23:14:13 3des kernel: Jan 25 23:14:13 3des kernel: CONTINUE? yes Disk is 100% alive, got same on other HW. fsck -y - have no this strange problem with reading. Is it OK "CANNOT READ BLK ..." ? >From my rc.conf: fsck_y_enable="YES" # Set to YES to do fsck -y if the initial preen fails. fsck_y_flags="-T ffs:-R,-r -T ufs:-R,-r" # Additional flags for fsck -y background_fsck="NO"# Attempt to run fsck in the background where possible. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
