Bug 562044
| Summary: | e2fsck does not correct all errors in filesystem | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Lachlan McIlroy <lmcilroy> | ||||||
| Component: | e2fsprogs | Assignee: | Eric Sandeen <esandeen> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | BaseOS QE - Apps <qe-baseos-apps> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 5.3 | CC: | bnater, sct, vgaikwad | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | e2fsprogs-1.39-31.el5 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | |||||||||
| : | 676465 683149 (view as bug list) | Environment: | |||||||
| Last Closed: | 2011-07-21 09:07:36 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 676465, 683149 | ||||||||
| Attachments: |
|
||||||||
|
Description
Lachlan McIlroy
2010-02-05 05:20:56 UTC
Created attachment 388974 [details]
Output from e2fsck -y from first pass at repairing filesystem image
Note that the appl_lv.e2i_2.bz2 e2image needs at least 532GB of disk space to unpack. There are tools to turn 0s into sparseness, that can help. -Eric Eric, What are these tools you mention? Unpacking a raw e2image needs to put blocks back into their original locations - is there a way I can unpack this image to a sparse file backed storage? Lachlan Ok, thanks Lachlan. make-sparse.c is at a few places - for example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=236383#24 testing newer e2fsprogs might be worthwhile. -Eric out of curiosity, what happened to this fs? Looks like a mess ... I'm not sure how this filesystem got into this state. It's from a customer and they reported that they had filesystems that could not be repaired - fsck was aborting with HTREE errors. They gave us two e2images; the first had HTREE errors but we had no problem repairing it and this is the second one which had no HTREE errors but I did find this problem. With the provided image I do see the unrepaired errors after the first pass; just a few things on the 2nd pass. I'll try it out again w/ newer e2fsprogs to see if this is something that's been fixed already. If they are hitting errors that we don't see, which arch were they on? -Eric They are using x86_64 systems. The filesystem is on LVM if that helps at all. e2fsck 1.41.9 behaves the same way, so I'll have to go looking for why it's not cleaning it up on the first pass. (it's pretty minimal problems on the 2nd pass, just one block group off by 1 block marked as used that is not claimed by any file) -Eric (In reply to comment #3) > There are tools to turn 0s into sparseness, that can help. To uncompress to a sparse file, "cp" can help: $ bzcat file.bz2 | cp --sparse=always /dev/stdin file.output Sent a patch, and an explanation of what's going wrong, upstream: http://marc.info/?l=linux-ext4&m=129727690603767&w=2 We'll see what the maintainer says about it. The fix is simple enough but it feels a little like a bandaid. Should suffice though, and fixes this testcase. We've got a reproducer and a candidate patch for this, so I'll go ahead & devel_ack+ it, and clone it to rhel6 (since the bug persists upstream) Created attachment 478076 [details]
Small testcase filesystem
This fs image should replicate the problem; 2nd fsck finds block bitmap problems as with the larger customer image.
Tagged & built in e2fsprogs-1.39-31.el5 An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-1080.html An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-1080.html |