public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Jim Meyering <jim@meyering.net>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: efficient access to "rotational";  new fcntl?
Date: Fri, 18 Sep 2009 18:16:58 -0400	[thread overview]
Message-ID: <20090918221658.GB28781@mit.edu> (raw)
In-Reply-To: <87vdjgqcbd.fsf@meyering.net>

On Fri, Sep 18, 2009 at 09:31:50PM +0200, Jim Meyering wrote:
>     chgrp, chmod, chown, chcon, du, rm: now all display linear performance,
>     even when operating on million-entry directories on ext3 and ext4 file
>     systems.  Before, they would exhibit O(N^2) performance, due to linear
>     per-entry seek time cost when operating on entries in readdir order.
>     Rm was improved directly, while the others inherit the improvement
>     from the newer version of fts in gnulib.

Excellent!  I didn't know that (since my userspace is still Ubuntu
9.04, which is still using coreutils 6.10).

> However, with e.g., an ext4 partition on non-rotational hardware like
> an SSD, that preprocessing is unnecessary and in fact wasted effort.
> I'd like to avoid the waste by querying the equivalent of
> /sys/.../rotational, via a syscall like fcntl or statvfs,
> given a file descriptor.

Have you benchmarked it both ways?  The preprocessing will cost some
extra CPU time, sure, but for a sufficiently large directory, or if
the user is deleting a very large directory hierarchy, such that "rm
-rf" spans multiple journal transactions, deleting the files in inode
order will still avoid some filesystem metadata blocks getting written
multiple times (which for SSD's, especially the crappier ones with
nasty write amplification factors) could show a performance impact.

> Is there an efficient way to get that single bit?

Not today; if it's really useful, we could add it, of course.  But how
much overhead are you trying to avoid by avoiding the pre-processing
before unlinking the files?

Regards,

						- Ted

  reply	other threads:[~2009-09-18 22:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-18 19:31 efficient access to "rotational"; new fcntl? Jim Meyering
2009-09-18 22:16 ` Theodore Tso [this message]
2009-09-19  8:01   ` Jim Meyering
2009-09-19  8:31     ` Arjan van de Ven
2009-09-19  9:07       ` Jim Meyering
2009-09-19  9:19         ` Arjan van de Ven
2009-09-19 11:11           ` Avi Kivity
2009-09-19 11:30             ` Arjan van de Ven
2009-09-19 11:40               ` Avi Kivity
2009-09-19 11:25 ` Willy Tarreau

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=20090918221658.GB28781@mit.edu \
    --to=tytso@mit.edu \
    --cc=jim@meyering.net \
    --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