All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Fedyk <mfedyk@matchmail.com>
To: Richard Gooch <rgooch@ras.ucalgary.ca>
Cc: Andrew Morton <akpm@zip.com.au>, Ben Israel <ben@genesis-one.com>,
	linux-kernel@vger.kernel.org
Subject: Re: File System Performance
Date: Mon, 12 Nov 2001 15:07:40 -0800	[thread overview]
Message-ID: <20011112150740.B32099@mikef-linux.matchmail.com> (raw)
In-Reply-To: <00b201c16b81$9d7aaba0$5101a8c0@pbc.adelphia.net> <3BEFF9D1.3CC01AB3@zip.com.au> <00da01c16ba2$96aeda00$5101a8c0@pbc.adelphia.net> <3BF02702.34C21E75@zip.com.au> <200111121959.fACJxsj08462@vindaloo.ras.ucalgary.ca>
In-Reply-To: <200111121959.fACJxsj08462@vindaloo.ras.ucalgary.ca>

On Mon, Nov 12, 2001 at 12:59:54PM -0700, Richard Gooch wrote:
> Here's an idea: add a "--compact" option to tar, so that it creates
> *all* inodes (files and directories alike) in the base directory, and
> then renames newly created entries to shuffle them into their correct
> positions. That should limit the number of block groups that are used,
> right?
> 
> It would probably also be a good idea to do that for cp as well, so
> that when I do a "cp -al" of a virgin kernel tree, I can keep all the
> directory inodes together. It will make a cold diff even faster.
> 

I don't think that would help at all... With the current file/dir allocator
it will choose a new block group for each directory no matter what the
parent is...

The new allocator would spread them accross the different block groups only
if they are created *directly* off of the root of the FS. Your idea would
make things worse for the new allocator *if* the tree is uncompressed into
the root of the FS, and *no* difference if not...

Mike

  reply	other threads:[~2001-11-12 23:08 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-12 13:54 File System Performance Ben Israel
2001-11-12 16:33 ` Andrew Morton
2001-11-12 17:50   ` Ben Israel
2001-11-12 19:46     ` Andrew Morton
2001-11-12 19:59       ` Richard Gooch
2001-11-12 23:07         ` Mike Fedyk [this message]
2001-11-13  0:04           ` Richard Gooch
2001-11-13  0:08             ` Mike Fedyk
2001-11-13  0:26               ` Richard Gooch
2001-11-13  0:47                 ` Mike Castle
2001-11-13  1:28                 ` Mike Fedyk
2001-11-13  6:34                   ` Richard Gooch
2001-11-13 20:56                     ` Andreas Dilger
2001-11-13  7:45             ` Andreas Dilger
2001-11-12 20:06       ` Steve Lord
2001-11-12 20:41         ` Andrew Morton
2001-11-12 21:27           ` Steve Lord
2001-11-12 21:43             ` Andrew Morton
2001-11-12 21:45               ` Steve Lord
2001-11-12 21:48               ` Linus Torvalds
2001-11-12 22:11                 ` Lionel Bouton
2001-11-12 19:41                   ` Gérard Roudier
2001-11-12 22:14                   ` Linus Torvalds
2001-11-12 22:30                     ` Ragnar Kjørstad
2001-11-12 22:36                     ` Andrew Morton
2001-11-12 23:04                       ` Mike Castle
2001-11-13  9:56                         ` Peter Wächtler
2001-11-13  9:41                     ` Henning P. Schmiedehausen
2001-11-12 22:16                 ` Andrew Morton
2001-11-12 22:26                   ` Steve Lord
2001-11-12 22:32                   ` Lionel Bouton
2001-11-12 22:45                     ` Alan Cox
2001-11-12 22:39                   ` Alan Cox
2001-11-12 22:39                     ` Xavier Bestel
2001-11-12 22:46                   ` Mike Castle
2001-11-12 21:53             ` Lionel Bouton
2001-11-13  0:17           ` Andreas Dilger
2001-11-13  0:40             ` Peter J . Braam
2001-11-13 20:46               ` Andreas Dilger
2001-11-16 22:07                 ` Peter J . Braam
2001-11-16 23:14                   ` Mike Fedyk
2001-11-12 16:40 ` Ben Israel
2001-11-12 17:29 ` Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2001-11-12 22:36 Grant Erickson

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=20011112150740.B32099@mikef-linux.matchmail.com \
    --to=mfedyk@matchmail.com \
    --cc=akpm@zip.com.au \
    --cc=ben@genesis-one.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rgooch@ras.ucalgary.ca \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.