2013-12-14 00:09:22

by bugzilla-daemon

[permalink] [raw]
Subject: [Bug 66951] New: filesystems should reserve inodes for root as they do disk space

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: [email protected]
Reporter: [email protected]
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.


2013-12-16 13:14:47

by Carlos Maiolino

[permalink] [raw]
Subject: Re: [Bug 66951] New: filesystems should reserve inodes for root as they do disk space

Hi,

On Sat, Dec 14, 2013 at 12:09:19AM +0000, [email protected] wrote:
> 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: [email protected]
> Reporter: [email protected]
> 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?
>
Yes, having an inode amount reserved for root might be good to avoid these
cases.

> 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.
>
Sorry, but you're wrong here.

Almost all good system administrators knows the importance of keep directories
like /home and /var in different filesystems, for simply 2 reasons:
- Keep system data separated from user data
- /var will store logs, and this might be HUGE in some cases.

And also, most distros I know of keeps /var and /home separated in their default
installations.

So, there is no excuse to keep /home and /var in different filesystems. Even if
you have just a single user, keep a separate /home filesystem is always
recommended.

> 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).
>
I agree that change the inode capacity wouldn't make the system behave any
better.

> 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.
>
Agreed indeed.

> 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?
>
I'm not sure how feasible it is or if is there any kind of job being done or
already done in this area, but is a good idea and I just added it to my TODO
list.

In the meantime, this isn't just a matter of how ext4 behaves regarding the
amount of inode, but looks like a BUG in your browser, or maybe you're accessing
a site which creates thousands of inodes?

--
Carlos