linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 66951] New: filesystems should reserve inodes for root as they do disk space
Date: Sat, 14 Dec 2013 00:09:19 +0000	[thread overview]
Message-ID: <bug-66951-13602@https.bugzilla.kernel.org/> (raw)

https://bugzilla.kernel.org/show_bug.cgi?id=66951

            Bug ID: 66951
           Summary: filesystems should reserve inodes for root as they do
                    disk space
           Product: File System
           Version: 2.5
    Kernel Version: 3.11.10
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: ext4
          Assignee: fs_ext4@kernel-bugs.osdl.org
          Reporter: kernelbugs@tecnopolis.ca
        Regression: No

I had a runaway non-root user process (Opera browser actually) exhaust all of
the inodes on my / (root) filesystem (ext4) by creating millions of 10 to 50
byte cache files in /home (which is not a separate partition on my system). 
Linux & ext4 happily allowed this program to cripple the whole system until I
figured out a) inodes were exhausted and b) what app was causing it and where
they all were, and c) rm -rf them all.

We all know filesystems like ext2/3/4 reserve a (tunable) amount of space for
root use only if a disk fills beyond a certain threshold.  I find it shocking
that a similar mechanism does not exist for inodes.  Most *NIX geeks I know
also can't believe it.  Do you find it shocking too?

One could argue I should have /home on a separate partition, but this is a
non-solution because all it takes is one user-writable directory in / (root)
such as /var/tmp.  Sure, then you could say /var should be a separate
partition, but let's be realistic: 95%+ of systems out there will not have a
separate /home or /var partition (let alone both).  Also, no distros by default
create separate partitions for all of these.

One could argue you should have your inode capacity be set so large it would be
impossible to exhaust it before you run out of disk space.  That point is moot
because a program could create 0 byte files, thus allowing exhaustion of inodes
before free space (which would remain unchanged).  Besides, one should be
allowed to tune their inodes at fs creation time to suit their usage habits as
monitored over the years (such as looking at their usual NBPI and adding a 2 or
4X safety margin).

One could argue you could use quotas, but that seems unreasonable for the
average guy (like myself) to do on their home desktop computer that only they
use.

Can ext2/3/4 and the kernel be modified to reserve a (tunable) number of inodes
for root just as it does for disk space?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

             reply	other threads:[~2013-12-14  0:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-14  0:09 bugzilla-daemon [this message]
2013-12-16 13:14 ` [Bug 66951] New: filesystems should reserve inodes for root as they do disk space Carlos Maiolino

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=bug-66951-13602@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-ext4@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;
as well as URLs for NNTP newsgroup(s).