Trying to produce a livecd of current rawhide, I get as far as running resize2fs. That then spins at 100% without ever producing anything, as far as I can see. I've killed the process after it accumulated and hour of cpu time. Didn't seem to consume any memory, just spin...
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...