mke2fs (and mkreiserfs) core dumps

Hi,

I've got an interesting situation here where mke2fs and mkreiserfs core dump with the message: File size limit exceeded (core dumped)

I recently upgraded the storage device in this machine from a single IDE disk to a mirrored RAID running off a 3ware controller.

The disk was living off the primary controller as hda, I have since moved it to hdc and the cdrom to hda.

The kernel is 2.4.18-rc4 + Trond's NFS_ALL patch.

Some info:

# fdisk -l /dev/hdc

Disk /dev/hdc: 255 heads, 63 sectors, 4982 cylinders Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hdc1             1       638   5124703+  83  Linux
/dev/hdc2           639      4982  34893180   83  Linux
# cat /proc/partitions
major minor  #blocks  name

   8     0   97684760 sda
   8     1      16033 sda1
   8     2    1052257 sda2
   8     3   40965750 sda3
   8     4   55649160 sda4
  22     0   40020624 hdc
  22     1    5124703 hdc1
  22     2   34893180 hdc2
# mke2fs /dev/hdc1
mke2fs 1.25 (20-Sep-2001)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
641280 inodes, 1281175 blocks
64058 blocks (5.00%) reserved for the super user
First data block=0
40 block groups
32768 blocks per group, 32768 fragments per group
16032 inodes per group
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736

File size limit exceeded (core dumped)
#

Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 21
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:04.1

    ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio

hda: ASUS CD-S500/A, ATAPI CD/DVD-ROM drive
hdc: Maxtor 54098U8, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hdc: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=79406/16/63, UDMA(66)
hda: ATAPI 50X CD-ROM drive, 128kB Cache, UDMA(33)

Anyone have any ideas? Could it be a bios setting?

Thanks,
Dave

This is a ulimit bug caused by the kernel and libc 2.1. If you log into the system as root at the console (no su) it should work.

I thought that the fix for this was in the 2.4.18 kernel, but I guess not.

Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert

Thanks for the info. This explains why I didn't have any problems partitioning the 3ware's RAID, I was logged into the console.

Is there anyway I can avoid logging into the console? It can be a PITA if the machine happens to be far away.

Thanks,
Dave

If you don't have any "ulimit" calls in the login, it should also be OK. It's just that some vendor startup scripts set a ulimit for non-root users. Trying to set it back to "unlimited" doesn't work.

Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert

Also check your PAM configuration files, since pam_limits can also be causing the problem. (Namely, any attempt to set the filesize to be "unlimited" cause it to be capped at 2GB.) There's also the question whether or not filesize limits should really apply to device files, since the original point of filesize limits were as a simple-minded quota control mechanism, and there seems to be little point to causing attempts to access block deivces to fail --- under what circumstances would this *ever* be considered a useful thing?

Anyway, as of e2fsprogs 1.27, since I got tired of handling user questions about this, e2fsprogs will attempt to unlimit filesize unconditionally, if it has the superuser privileges to do so. Because of the fact that in effect, the kernel ABI changed between 2.2 and 2.4 (the value of "Unlimited" change), in e2fsprogs I had to hard-code the value of unlimited, so that it would do the right thing regardless of which header files were used to compile e2fsprogs. (Oh, joy, oh rapture.)

- Ted

Yes, I have always considered this a kernel bug (introduced in 2.4.10), but my (admittedly feeble) attempts to get it fixed were not accepted. At one point I thought a fix went into 2.4.18-pre[12] or so, but I guess not. I haven't tried in a while, so maybe I should make another attempt.

Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert

Was that part of the 2.4.10-pre11 -aa VM merge, or was it from another seperate patch?

Well, at the same time as Linus merged -aa VM, he also merged blockdev-in-pagecache from -aa. This caused this problem, among others. With blockdev-in-pagecache, the kernel thinks block device access is the same as reading a file, so it imposes file limits. It also caused the problem that the block device (pagecache) and the filesystem (buffer cache) were not coherent, causing e2fsck, tune2fs, etc to not work.

Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert

Ahh yes, I remember now.

Right.

This was fixed in 2.4.12 I believe.

I also heard one offhand remark that similar problems have crept back into the kernel recently. Is that true?