[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: core dumped messages from tune2fs



On Nov 23, 2001  16:48 -0700, Andreas Dilger wrote:
> On Nov 23, 2001  13:12 +0000, Stephen C. Tweedie wrote:
> > On Thu, Nov 22, 2001 at 07:09:20PM -0500, Stephen Clark wrote:
> > > [root joker /root]# tune2fs -j /dev/hdc4
> > > tune2fs 1.25 (20-Sep-2001)
> > > Creating journal inode: done
> > > This filesystem will be automatically checked every 20 mounts or
> > > 180 days, whichever comes first.  Use tune2fs -c or -i to override.
> > > File size limit exceeded (core dumped)
> > 
> > Sounds like the current 2.4 core VFS bug which applies "ulimit" file
> > size limits to blkock devices.  The workaround for now is to log in
> > directly as root instead of logging in as a user with limits and then
> > "su"ing to root.
> 
> Probably shouldn't core dump, though.  It should fail gracefully, for
> sure.  In this situation (creating a journal on an existing fs) it may
> have to write past 2GB into the fs, which is unfortunate, but likely
> the source of the problem.  I'll see if I can find anything.

Grr, it _looks_ like this is a problem in libc, but I haven't checked
closely.  Running under GDB with a suitably limited "unlimited" setup:

tune2fs 1.25 (20-Sep-2001)
Creating journal inode: done
This filesystem will be automatically checked every 26 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Program received signal SIGXFSZ, File size limit exceeded.
0x400d7684 in __libc_write () from /lib/libc.so.6
(gdb) info stack
#0  0x400d7684 in __libc_write () from /lib/libc.so.6
#1  0x4002cf20 in __DTOR_END__ () from /lib/libext2fs.so.2
#2  0x4002a1a9 in unix_write_blk () from /lib/libext2fs.so.2
#3  0x40022cbc in ext2fs_flush () from /lib/libext2fs.so.2
#4  0x40022de3 in ext2fs_close () from /lib/libext2fs.so.2
#5  0x804a585 in main (argc=3, argv=0xbffff9f4) at tune2fs.c:792

This must be because it is flushing out superblock copies or updating
block bitmaps at the end or something.  I had a similar failure (but
no core dump) when removing the journal to test it, and e2fsck was
complaining about the block bitmap, even though all of the referenced
blocks were < 2GB offset as was the block bitmap itself.  Probably
writing in some strange order, I imagine.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]