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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Sat, Dec 14, 2013 at 12:09:19AM +0000, bugzilla-daemon@xxxxxxxxxxxxxxxxxxx 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: fs_ext4@xxxxxxxxxxxxxxxxxxxx
>           Reporter: kernelbugs@xxxxxxxxxxxxx
>         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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux