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)
#
>From dmesg:
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
On Mar 13, 2002 12:31 -0800, David Rees wrote:
> I've got an interesting situation here where mke2fs and mkreiserfs core dump
> with the message: File size limit exceeded (core dumped)
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.
> The kernel is 2.4.18-rc4 + Trond's NFS_ALL patch.
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
On Wed, Mar 13, 2002 at 01:55:37PM -0700, Andreas Dilger wrote:
> On Mar 13, 2002 12:31 -0800, David Rees wrote:
> > I've got an interesting situation here where mke2fs and mkreiserfs core dump
> > with the message: File size limit exceeded (core dumped)
>
> 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.
>
> > The kernel is 2.4.18-rc4 + Trond's NFS_ALL patch.
>
> I thought that the fix for this was in the 2.4.18 kernel, but I guess
> not.
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
On Mar 13, 2002 13:37 -0800, David Rees wrote:
> On Wed, Mar 13, 2002 at 01:55:37PM -0700, Andreas Dilger wrote:
> > On Mar 13, 2002 12:31 -0800, David Rees wrote:
> > > I've got an interesting situation here where mke2fs and mkreiserfs core dump
> > > with the message: File size limit exceeded (core dumped)
> >
> > 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.
> >
> > > The kernel is 2.4.18-rc4 + Trond's NFS_ALL patch.
> >
> > I thought that the fix for this was in the 2.4.18 kernel, but I guess
> > not.
>
> 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.
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
Hi,
> 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
Not exactly, there's a trap: Some models have a
/etc/security/limits.conf which might ulimit some stuff even though you
don't have any direct calls to ulimit. I had already encountered this
several times and wondered if I might consider this a misbehavior.
Anyway, these limits don't apply to root then in the model. I don't know
if this problem is based on that.
Thunder
On Wed, Mar 13, 2002 at 02:54:20PM -0700, Andreas Dilger wrote:
>
> 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.
>
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
On Mar 15, 2002 18:23 -0500, Theodore Tso wrote:
> 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?
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
On Sun, Mar 17, 2002 at 12:26:53AM -0700, Andreas Dilger wrote:
> On Mar 15, 2002 18:23 -0500, Theodore Tso wrote:
> > 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?
>
> 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.
>
Was that part of the 2.4.10-pre11 -aa VM merge, or was it from another
seperate patch?
On Sun, Mar 17, 2002 at 08:03:17PM -0700, Andreas Dilger wrote:
> On Mar 17, 2002 10:37 -0800, Mike Fedyk wrote:
> > On Sun, Mar 17, 2002 at 12:26:53AM -0700, Andreas Dilger wrote:
> > > 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.
> > >
> >
> > 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.
Ahh yes, I remember now.
> 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
Right.
> problem that the block device (pagecache) and the filesystem (buffer
> cache) were not coherent, causing e2fsck, tune2fs, etc to not work.
>
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?
On Mar 17, 2002 10:37 -0800, Mike Fedyk wrote:
> On Sun, Mar 17, 2002 at 12:26:53AM -0700, Andreas Dilger wrote:
> > 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.
> >
>
> 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
Hi!
I am exeperiencing the similar problem in kernel
2.4.18, glibc 2.2.5, and patched gcc 2.95.3
(http://ricardo.ecn.wfu.edu/glib-linux-archive/0110/0
007.html).
Both of the following commands
mke2fs /dev/md0
mke2fs -j /dev/md0
output
File size limit exceeded
Please help and thank you in advance!
CN
--------------------------------------------------------
You too can have your own email address from Eurosport.
http://www.eurosport.com
On Jun 11, 2002 02:01 +0000, [email protected] wrote:
> I am exeperiencing the similar problem in kernel
> 2.4.18, glibc 2.2.5, and patched gcc 2.95.3
> (http://ricardo.ecn.wfu.edu/glib-linux-archive/0110/0
> 007.html).
>
> Both of the following commands
>
> mke2fs /dev/md0
> mke2fs -j /dev/md0
>
> output
>
> File size limit exceeded
You must log in directly at the console as root (no su or sudo), or
disable any ulimit from being set.
Alternately, if you get the very latest e2fsprogs (1.27) then it
should also be able to work around this problem.
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
Thank you! Andreas,
I do directly login at the console as root and
e2fsprogs-1.27 is used. ulimit is not set.
CN
-------------
<< You must log in directly at the console as root
(no su or sudo), or disable any ulimit from being
set.
Alternately, if you get the very latest e2fsprogs
(1.27) then it
should also be able to work around this problem. >>
--------------------------------------------------------
You too can have your own email address from Eurosport.
http://www.eurosport.com