Bug 506105 - resize2fs spins in livecd-creator
resize2fs spins in livecd-creator
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-15 11:38 EDT by Matthias Clasen
Modified: 2009-08-03 22:03 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-03 22:03:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthias Clasen 2009-06-15 11:38:46 EDT
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...
Comment 1 Eric Sandeen 2009-06-16 11:33:35 EDT
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
Comment 2 Mads Kiilerich 2009-06-17 12:35:37 EDT
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?
Comment 3 Eric Sandeen 2009-06-17 12:42:03 EDT
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
Comment 4 Matthias Clasen 2009-06-17 13:13:23 EDT
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.
Comment 5 Eric Sandeen 2009-06-17 13:21:44 EDT
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
Comment 6 Matthias Clasen 2009-06-17 14:06:25 EDT
I'll try tonight
Comment 7 Matthias Clasen 2009-07-06 10:50:44 EDT
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...

Note You need to log in before you can comment on or make changes to this bug.