From: Theodore Ts'o <tytso@mit.edu>
To: Jim Meyering <jim@meyering.net>
Cc: "Andreas Dilger" <adilger@dilger.ca>,
"Niklas Hambüchen" <niklas@nh2.me>,
"Linux FS-devel Mailing List" <linux-fsdevel@vger.kernel.org>,
"Paul Eggert" <eggert@cs.ucla.edu>,
"Pádraig Brady" <P@draigbrady.com>
Subject: Re: O(n^2) deletion performance
Date: Tue, 2 Jan 2018 01:22:46 -0500 [thread overview]
Message-ID: <20180102062245.GJ2532@thunk.org> (raw)
In-Reply-To: <CA+8g5KHLx6t_naqXbXskKX-k-tG9J-Hg+cLR8EBO1cqsSLbt3g@mail.gmail.com>
On Mon, Jan 01, 2018 at 08:27:48PM -0800, Jim Meyering wrote:
> Our goal (with fts and coreutils) has been to make it harder for an
> accident or maliciousness (with a few million entries in a directory)
> to hinder file system traversals. Of course, it's not just rm: any
> FS-traversal tool is affected: cp, chmod, chgrp, du, find, tar, etc.
> Sure, quotas can help, but even self-inflicted accidents happen on
> single-user systems with no quotas.
>
> Idly wondered if the default inode limits could save ext4 users? Perhaps not.
> In this 850GB file system, I see it has 48M inodes (caveat, I may have
> changed the default when I created it -- don't recall):
Well, it's a bit of a blunt hammer, but you *can* set a mount option
"mount -t ext4 -o max_dir_size_kb=512" which will not allow the
directory to grow larger than 512k (or pick your favorite limit).
To me that's like putting a speed limit governer on a car because you
don't trust the driver not to exceed some arbitrary (sometimes opposed
by politicians who think they know better) limit. Personally, I would
be super annoyed if my car was outfitted with something which didn't
let me go faster than 90 km/h or 56 mph. But, apparently many
commercial vehciles, particular in the UK, do have such things.
But if you don't trust your users, the feature is there for a
sysadmin/BOFH to impose on said users; but personally, it's relatively
rare thing, and when trading off between the pain caused by hitting an
artificially imposed limit, versus the patience needed to recover from
accidentally dumping 16 million files into a directory --- I prefer
the latter. I can wait a few minutes....
- Ted
next prev parent reply other threads:[~2018-01-02 6:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-02 0:21 O(n^2) deletion performance Niklas Hambüchen
2018-01-02 1:20 ` Niklas Hambüchen
2018-01-02 1:59 ` Theodore Ts'o
2018-01-02 2:49 ` Andreas Dilger
2018-01-02 4:27 ` Jim Meyering
2018-01-02 6:22 ` Theodore Ts'o [this message]
2018-01-04 4:16 ` Jim Meyering
2018-01-04 7:16 ` Theodore Ts'o
2018-01-04 11:42 ` Dave Chinner
2018-01-02 4:33 ` Theodore Ts'o
2018-01-02 4:54 ` Dave Chinner
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=20180102062245.GJ2532@thunk.org \
--to=tytso@mit.edu \
--cc=P@draigbrady.com \
--cc=adilger@dilger.ca \
--cc=eggert@cs.ucla.edu \
--cc=jim@meyering.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=niklas@nh2.me \
/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).