Bug 506105
| Summary: | resize2fs spins in livecd-creator | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Matthias Clasen <mclasen> |
| Component: | e2fsprogs | Assignee: | Eric Sandeen <esandeen> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | esandeen, kzak, mads, oliver |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-08-04 02:03:07 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: | |||
|
Description
Matthias Clasen
2009-06-15 15:38:46 UTC
Ah, the neverending resize2fs fun ;)
So it's a single resize2fs that is running, rather than new ones getting spawned by the scripts? (I had seen the latter... and sent a patch like this for it):
--- /usr/lib/python2.6/site-packages/imgcreate/fs.py.orig 2009-05-20 14:57:22.135687800 -0500
+++ /usr/lib/python2.6/site-packages/imgcreate/fs.py 2009-05-20 14:57:46.168760786 -0500
@@ -448,7 +448,7 @@
#
bot = 0
top = self.__get_size_from_filesystem()
- while top != (bot + 1):
+ while top != (bot + 1) and (top - bot) > 16384:
t = bot + ((top - bot) / 2)
if not resize2fs(self.disk.lofile, t):
Can you reproduce it? If it's a single resize2fs instance spinning we'll need to get hold of an image of the filesystem it's trying to resize, then I can reproduce & fix it. A patch like the one in https://bugzilla.redhat.com/show_bug.cgi?id=505339#c1 could help gather that image.
Thanks,
-Eric
I just hit the bug and distilled a testcase from livecd-creator before I searched bz and found this and 496982 and 505339.
My initial thoughts on this was that it was OK that the resize left the file system in a state where fsck wants to do _something_, but it shouldn't return 1 for "File system _errors_ corrected". And it seems strange that it says that file system was modified without telling _what_.
You still need a reproducible test case? Does this work for you?
[root@localhost ~]# dd if=/dev/zero of=img bs=1 count=0 seek=3000M
0+0 records in
0+0 records out
0 bytes (0 B) copied, 1.6321e-05 s, 0.0 kB/s
[root@localhost ~]# /sbin/mkfs.ext4 -F img
mke2fs 1.41.4 (27-Jan-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
192000 inodes, 768000 blocks
38400 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=788529152
24 block groups
32768 blocks per group, 32768 fragments per group
8000 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 38 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
[root@localhost ~]# /sbin/e2fsck -f -v img
e2fsck 1.41.4 (27-Jan-2009)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
11 inodes used (0.01%)
0 non-contiguous files (0.0%)
0 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 1
29572 blocks used (3.85%)
0 bad blocks
1 large file
0 regular files
2 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
--------
2 files
[root@localhost ~]# /sbin/resize2fs img 150M
resize2fs 1.41.4 (27-Jan-2009)
Resizing the filesystem on img to 38400 (4k) blocks.
The filesystem on img is now 38400 blocks long.
[root@localhost ~]# /sbin/e2fsck -f -v img
e2fsck 1.41.4 (27-Jan-2009)
Backing up journal inode block information.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
img: ***** FILE SYSTEM WAS MODIFIED *****
11 inodes used (0.07%)
0 non-contiguous files (0.0%)
0 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 1
17772 blocks used (46.28%)
0 bad blocks
1 large file
0 regular files
2 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
--------
2 files
[root@localhost ~]# echo $?
1
Finally: If I resize directly to 100M then it fails. Resizing to 150M first makes it succeed. That is perhaps another incarnation of the same bug?
Mads, thank you! I'll give that a shot. This is more likely related to bug #505339 than this one. Matthias, I'd still like to know just what you mean by "spin" Thanks, -Eric Eric, what I tried to describe by 'spin' was running for hours without any apparent progress, eating a lot of cpu time and almost no memory. Matthias, ok so I guess it's a single resize2fs instance that isn't progressing? If you can reproduce it, can you maybe use gdb or strace to attach to it and see what's going on? Thanks, -Eric I'll try tonight Hitting this again in todays rawhide. I see resize2fs run forever at 99-100% cpu without ever making any syscalls. Rerunning the same resize2fs command that livecd-creator runs by hand with -d 14 yields the following output: resize2fs 1.41.7 (29-June-2009) Resizing the filesystem on /var/tmp/imgcreate-LLhQ5b/tmp-v8G81m/ext3fs.img to 588768 (4k) blocks. Number of free blocks: 2179/2083, Needed: 96 Moving 96 blocks 588768->526237 ino=134422, blockcnt=0, 588800->526269 ino=134422, blockcnt=1, 588801->526270 ino=134422, blockcnt=2, 588802->526271 ino=134422, blockcnt=3, 588803->526272 ino=134422, blockcnt=4, 588804->526273 ino=134422, blockcnt=5, 588805->526274 ino=134423, blockcnt=0, 588806->526275 ino=134423, blockcnt=1, 588807->526276 ino=134423, blockcnt=2, 588808->526277 ino=134423, blockcnt=3, 588809->526278 ino=134423, blockcnt=4, 588810->526279 ino=134423, blockcnt=5, 588811->526280 ino=134424, blockcnt=0, 588814->526283 ino=134424, blockcnt=1, 588815->526284 ino=134424, blockcnt=2, 588816->526285 ino=134424, blockcnt=3, 588817->526286 ino=134424, blockcnt=4, 588818->526287 ino=134424, blockcnt=5, 588819->526288 ino=134425, blockcnt=0, 588829->526298 ino=134425, blockcnt=1, 588830->526299 ino=134425, blockcnt=2, 588831->526300 ino=134425, blockcnt=3, 588832->526301 ino=134425, blockcnt=4, 588833->526302 ino=134425, blockcnt=5, 588834->526303 ino=134426, blockcnt=0, 588835->526304 ino=134426, blockcnt=1, 588836->526305 ino=134426, blockcnt=2, 588837->526306 ino=134426, blockcnt=3, 588838->526307 ino=134426, blockcnt=4, 588839->526308 ino=134426, blockcnt=5, 588840->526309 ino=134427, blockcnt=0, 588841->526310 ino=134427, blockcnt=1, 588842->526311 ino=134427, blockcnt=2, 588843->526312 ino=134427, blockcnt=3, 588844->526313 ino=134427, blockcnt=4, 588845->526314 ino=134427, blockcnt=5, 588846->526315 ino=134428, blockcnt=0, 588847->526316 ino=134428, blockcnt=1, 588848->526317 ino=134429, blockcnt=0, 588849->526318 ino=134430, blockcnt=0, 588850->526319 ino=134430, blockcnt=1, 588851->526320 ino=134430, blockcnt=2, 588852->526321 ino=134430, blockcnt=3, 588853->526322 ino=134430, blockcnt=4, 588854->526323 ino=134430, blockcnt=5, 588855->526324 ino=134431, blockcnt=0, 588856->526325 ino=134431, blockcnt=1, 588857->526326 ino=134431, blockcnt=2, 588858->526327 ino=134431, blockcnt=3, 588859->526328 ino=134431, blockcnt=4, 588860->526329 ino=134431, blockcnt=5, 588861->526330 ino=134431, blockcnt=6, 588862->526331 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 ino=134432, blockcnt=0, 588863->526332 and this then repeats forever... |