[LU-15265] e2fsck test reports "Free blocks count wrong for group #705232 (33791, counted=32768)" Created: 22/Nov/21  Updated: 22/Apr/22  Resolved: 22/Apr/22

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: Lustre 2.15.0
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: Prasannakumar Nagasubramani Assignee: Artem Blagodarenko (Inactive)
Resolution: Cannot Reproduce Votes: 0
Labels: None
Environment:

Configuration:

20 x Lustre 2.15 clients

4 X LNet routers

Lustre client:

2.14.55_81_gc26b347

NEO build: 6.0-65-cm-21.10.24-g2c588a6

Lustre server:

2.14.55_81_gc26b347

Model SSUs

1xE1000D 1xE1000F

4 x OSS nodes with 2 x HDD OSTs and 2 x flash OSTs


Issue Links:
Related
is related to LU-15238 lfsck crashes MDT LDISKFS-fs error (d... Open
Severity: 3
Rank (Obsolete): 9223372036854775807

 Description   

e2fsck test reports "Free blocks count wrong for group #705232 (33791, counted=32768)" errors.

Pass 5: Checking group summary information
Block bitmap differences:  -23109042175
Fix? no
Free blocks count wrong for group #705232 (33791, counted=32768).
Fix? no
Free blocks count wrong for group #705252 (33784, counted=32768).
Fix? no
Free blocks count wrong for group #705279 (32762, counted=32767).
Fix? no
Free blocks count wrong (98197275837, counted=98197372106).
Fix? no
Inode bitmap differences:  -2842413
Fix? no
Pass 5: Memory used: 202116k/222912k (97836k/104281k), time: 232.98/24.04/ 1.14
Pass 5: I/O read: 4805MB, write: 0MB, rate: 20.62MB/s 

Will upload the e2image and other e2fsck logs to FTP.



 Comments   
Comment by Prasannakumar Nagasubramani [ 22/Nov/21 ]

Test Name : Lustre File System Checking LDISKFS with e2fsck

Configuration:

20 x Lustre 2.15 clients

4 X LNet routers

Lustre client:

2.14.55_81_gc26b347

NEO build: 6.0-65-cm-21.10.24-g2c588a6

Lustre server:

2.14.55_81_gc26b347

Model SSUs

1xE1000D 1xE1000F

4 x OSS nodes with 2 x HDD OSTs and 2 x flash OSTs

Comment by Andreas Dilger [ 22/Nov/21 ]

The free block count in the group descriptors is likely to be updated if there are any repairs to the filesystem, which is not shown here, so there is no way to know if this information is useful or not. The free block count in the superblock is not kept up to date while the filesystem is mounted, so this is a very common situation. Also, there is absolutely no information here about what happened to the filesystem before e2fsck was run, so there isn't really anything useful that can be done here.

Comment by Prasannakumar Nagasubramani [ 22/Nov/21 ]

e2fsck logs, kern and messages are uploaded to FTP.
ftp.whamcloud.com: /uploads/LU15265

I hope /var/log/messages and /var/log/kern is pretty enough to know what happened prior to the e2fsck test. If not please let me know what else is needed.

Comment by Prasannakumar Nagasubramani [ 04/Dec/21 ]

e2image from the node uploaded to FTP.
/uploads/LU15265/kjcf05n05_image_out

Comment by Andreas Dilger [ 04/Dec/21 ]

Artem, could you please take a look.

Comment by Cory Spitz [ 06/Jan/22 ]

We need to check into the possibility that this issue is a side effect of LU-15404.

Comment by Colin Faber [ 20/Apr/22 ]

spitzcor,

Were you guys able to determine this?

-cf

Comment by Cory Spitz [ 20/Apr/22 ]

cfaber, no, we don't think it was associated with LU-15404, but we also can no longer reproduce it. I suppose we can resolve it and re-open later, if necessary. artem_blagodarenko, what do you think?
Thanks for following up, Colin.

Comment by Colin Faber [ 20/Apr/22 ]

Ok, Thanks spitzcor, I'll close this (pending artem_blagodarenko's assessment), if you see it again, please re-open.

-cf

Comment by Artem Blagodarenko (Inactive) [ 21/Apr/22 ]

>I suppose we can resolve it and re-open later, if necessary. artem_blagodarenko, what do you think?
Agree.
>Ok, Thanks spitzcor, I'll close this (pending artem_blagodarenko's assessment), if you see it again, please re-open.
cfaber , I have no objections

Comment by Colin Faber [ 21/Apr/22 ]

Closing, Cannot reproduce.

Thanks folks!

 

-cf

 

Generated at Sat Feb 10 03:16:51 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.