| Summary: | installer-initiated fs resize (shrink) leads to superblock/device size mismatch | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Reuben W. Perelman <reub2000> | ||||||||
| Component: | anaconda | Assignee: | David Lehman <dlehman> | ||||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 15 | CC: | dnlbtz, esandeen, jonathan, josef, kzak, oliver, vanmeeuwen+fedora | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | i686 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2011-10-19 17:56:44 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Attachments: |
|
||||||||||
|
Description
Reuben W. Perelman
2011-03-20 05:00:08 UTC
Sorry for the late reply here.
I'm not sure there's enough info to go on...
Somehow he ended up with:
> The filesystem size (according to the superblock) is 28672000 blocks
> The physical size of the device is 28671868 blocks
after, apparently, an anaconda resize.
If the fs was being shrunk, then it's
1) fs shrink
2) device shrink
If the device is too small, then I would tend to blame anaconda for shrinking it to a too-small size.
Punting to anaconda for now, for some eyeballs over there. Maybe this is a known/fixed issue.
Can you attach /tmp/anaconda.log, /tmp/storage.log, and /tmp/program.log to this bug report? If you've finished the installation, they'll be /var/log/anaconda.*. Thanks. To justify my punting ;) The device is too small by (28672000-28671868) or by 132 blocks. It seems quite unlikely (but possible) that the fs was shrunk by only 528k. Maybe the reporter can confirm... But, because the difference is only 528k, this does not seem like a case of "resize2fs forgot to update the superblock" - seems more likely that it was updated properly, and the device size is the root cause of the problem. I can't say with certainty, but it seems plausible :) Created attachment 512030 [details]
anaconda.log
Created attachment 512031 [details]
anaconda.program.log
Created attachment 512032 [details]
anaconda.storage.log
(In reply to comment #4) > Created attachment 512030 [details] > anaconda.log What exactly is the problem you are experiencing? The file system size of sda5 was 191 blocks bigger than the device size. Because the filesystem was mounted as /home, the system went into system maintanance mode after reboot (mount command detected the size mismatch). I think I see what's happening: we may adjust the new partition's end sector to ensure it is properly aligned, but we do not update the target size of its formatting accordingly. (In reply to comment #9) > I think I see what's happening: we may adjust the new partition's end sector to > ensure it is properly aligned, but we do not update the target size of its > formatting accordingly. I'm curious - where is this target size specified? I don't know of any mkfs that will allow a specification of a larger size than the device it's pointed at. If that works, it sounds like a mkfs bug... (In reply to comment #10) > (In reply to comment #9) > > I think I see what's happening: we may adjust the new partition's end sector to > > ensure it is properly aligned, but we do not update the target size of its > > formatting accordingly. > > I'm curious - where is this target size specified? I don't know of any mkfs > that will allow a specification of a larger size than the device it's pointed > at. If that works, it sounds like a mkfs bug... There is no mkfs call -- this is a resize of device and fs. Since the operation is a shrink, the fs is resized before the device. Er, right. Sorry. ("formatting" sounded like mkfs, and I went on a tangent.)
So the device is shrunk smaller than the shrunken fs due to the alignment.
FWIW, we don't care too much about the end sector alignment, unless that determines the next start sector.
There may not be a big reason to worry about moving the end sector around...
Fixed on rawhide. Will be in anaconda-17.2-1. |