From: Daniel Phillips <phillips@arcor.de>
To: Helge Hafting <helgehaf@aitel.hist.no>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] Improved inode number allocation for HTree
Date: Tue, 11 Mar 2003 21:19:11 +0100 [thread overview]
Message-ID: <20030311201511.EEBE6F94A2@mx12.arcor-online.net> (raw)
In-Reply-To: <20030311193903.GA15327@hh.idb.hist.no>
On Tue 11 Mar 03 20:39, Helge Hafting wrote:
> On Tue, Mar 11, 2003 at 02:41:06PM +0100, Daniel Phillips wrote:
> > <wishful thinking>
> > Now that you mention it, just locking out create and rename during
> > directory traversal would eliminate the pain. Delete is easy enough to
> > handle during traversal. For a B-Tree, coalescing could simply be
> > deferred until the traversal is finished, so reading the directory in
> > physical storage order would be fine. Way, way cleaner than what we have
> > to do now.
> > </wishful thinking>
>
> Ok, so "rm" works. Then you have things like "mv *.c /usr/src" to worry
> about.
That's equivalent to ls, the shell expands it before doing any moving. You
can construct something more interesting with ls | xargs <something nasty>
into the same directory. Since the user is trying to shoot their foot off,
let the lock be recursive, and let them do that.
> ...someone evil still
> could cause trouble by keeping a traversal going forever, creating one
> dummy file and deleting one whenever it makes progress. The directory
> would get big, filled up with placeholders until some ulimit kicks in.
>
> Helge Hafting
It's not clear that's any more evil than things they can do already, eg,
seq 1 1000000 | xargs -l1 cp -a /usr
Welllll, this is all idle speculation anyway. Nobody's going to fix the
flaw this week, if it's even possible (I suspect it is).
Regards,
Daniel
next prev parent reply other threads:[~2003-03-11 20:04 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-27 17:31 [Bug 417] New: htree much slower than regular ext3 Martin J. Bligh
2003-02-28 2:55 ` Daniel Phillips
2003-02-27 21:00 ` Andreas Dilger
2003-02-28 4:12 ` Daniel Phillips
2003-02-27 21:33 ` Martin J. Bligh
2003-03-13 21:04 ` [Ext2-devel] " Stephen C. Tweedie
2003-03-07 15:46 ` Alex Tomas
2003-03-08 17:38 ` Daniel Phillips
2003-03-07 23:27 ` Theodore Ts'o
2003-03-09 19:26 ` Alex Tomas
2003-03-09 7:08 ` Alex Tomas
2003-03-10 17:58 ` Daniel Phillips
2003-03-10 21:25 ` Theodore Ts'o
2003-03-11 21:57 ` Bill Davidsen
[not found] ` <20030307214833.00a37e35.akpm@digeo.com>
[not found] ` <20030308010424.Z1373@schatzie.adilger.int>
2003-03-09 22:54 ` [Ext2-devel] " Daniel Phillips
2003-03-08 23:19 ` Andrew Morton
2003-03-09 23:10 ` Daniel Phillips
[not found] ` <20030309184755.ACC80FCA8C@mx12.arcor-online.net>
[not found] ` <m3u1ecl5h8.fsf@lexa.home.net>
2003-03-10 20:45 ` [RFC] Improved inode number allocation for HTree Daniel Phillips
[not found] ` <3E6D1D25.5000004@namesys.com>
[not found] ` <20030311031216.8A31CEFD5F@mx12.arcor-online.net>
2003-03-11 10:45 ` Hans Reiser
2003-03-11 13:00 ` Helge Hafting
2003-03-11 13:41 ` Daniel Phillips
2003-03-11 17:16 ` Andreas Dilger
2003-03-11 19:39 ` Helge Hafting
2003-03-11 20:19 ` Daniel Phillips [this message]
2003-03-11 21:25 ` atomic kernel operations are very tricky to export to user space (was [RFC] Improved inode number allocation for HTree ) Hans Reiser
2003-03-11 23:49 ` Jamie Lokier
2003-03-10 20:48 ` [RFC] Improved inode number allocation for HTree Daniel Phillips
2003-03-10 21:04 ` John Bradford
2003-03-10 21:28 ` Andreas Schwab
2003-03-10 21:50 ` Filesystem write priorities, (Was: Re: [RFC] Improved inode number allocation for HTree) John Bradford
2003-03-14 21:55 ` [Ext2-devel] " Stephen C. Tweedie
2003-03-10 21:33 ` [RFC] Improved inode number allocation for HTree Daniel Phillips
2003-03-10 21:47 ` [Ext2-devel] " Bryan O'Sullivan
2003-03-10 22:02 ` Matthew Wilcox
2003-03-11 8:47 ` Jakob Oestergaard
2003-03-11 11:27 ` John Bradford
2003-03-14 21:57 ` Stephen C. Tweedie
2003-03-15 8:39 ` jw schultz
[not found] <20030311194014$426e@gated-at.bofh.it>
[not found] ` <20030311194014$1a3c@gated-at.bofh.it>
[not found] ` <20030311194014$78c3@gated-at.bofh.it>
[not found] ` <20030311194014$5811@gated-at.bofh.it>
[not found] ` <20030311194014$49a6@gated-at.bofh.it>
2003-03-11 20:14 ` Pascal Schmidt
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=20030311201511.EEBE6F94A2@mx12.arcor-online.net \
--to=phillips@arcor.de \
--cc=helgehaf@aitel.hist.no \
--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;
as well as URLs for NNTP newsgroup(s).