From: Theodore Tso <tytso@mit.edu>
To: David Rees <dbr@greenhydrant.com>, linux-kernel@vger.kernel.org
Subject: Re: mke2fs (and mkreiserfs) core dumps
Date: Fri, 15 Mar 2002 18:23:56 -0500 [thread overview]
Message-ID: <20020315182355.A1123@thunk.org> (raw)
In-Reply-To: <20020313123114.A11658@greenhydrant.com> <20020313205537.GC429@turbolinux.com> <20020313133748.A12472@greenhydrant.com> <20020313215420.GD429@turbolinux.com>
In-Reply-To: <20020313215420.GD429@turbolinux.com>; from adilger@clusterfs.com on Wed, Mar 13, 2002 at 02:54:20PM -0700
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
next prev parent reply other threads:[~2002-03-16 5:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-13 20:31 mke2fs (and mkreiserfs) core dumps David Rees
2002-03-13 20:55 ` Andreas Dilger
2002-03-13 21:37 ` David Rees
2002-03-13 21:54 ` Andreas Dilger
2002-03-15 23:23 ` Theodore Tso [this message]
2002-03-17 7:26 ` Andreas Dilger
2002-03-17 18:37 ` Mike Fedyk
2002-03-18 3:03 ` Andreas Dilger
2002-03-18 5:10 ` Mike Fedyk
-- strict thread matches above, loose matches on Subject: below --
2002-03-14 18:27 Thunder from the hill
2002-06-11 2:01 cnliou
2002-06-11 5:02 ` Andreas Dilger
2002-06-11 10:32 cnliou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020315182355.A1123@thunk.org \
--to=tytso@mit.edu \
--cc=dbr@greenhydrant.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox