From: mjt@nysv.org
To: Will Smith <will@willsmith.org>
Cc: reiserfs-list@namesys.com
Subject: Re: Benchmark : ext3 vs reiser4 and effects of fragmentation.
Date: Thu, 16 Sep 2004 18:03:48 +0300 [thread overview]
Message-ID: <20040916150348.GL26192@nysv.org> (raw)
In-Reply-To: <4149A843.7010804@willsmith.org>
On Thu, Sep 16, 2004 at 10:50:43PM +0800, Will Smith wrote:
>
>"This repacker goes through the entire tree ordering, from left to right
>and then from right to left, alternating each time it runs."
This is the default behavior, or?
I thought it scans through once per run and remembers which direction
was the last one.
But maybe I should look into the repacker some more before "opening my
mouth" ;)
>If I ran the repacker several times (left->right, right->left, and
>repeat) then fragmentation fell down to almost 0.
So I take it the direction oopses were fixed, good good :)
>(/etc/cron.daily/repacker.reiser4 or similar?) I'd be happy to
>write these if nobody else is - but it will be in /bin/bash shell.
There are some drawbacks. Sure essentially every Linux distro has
/bin/sh -> /bin/bash, but still it's a bit fishy to force bash.
Still I agree that bash is superior to sh.
I'd write it in Python, to have niftier getopts handling...
>2) the last-run-direction should be persistently stored per filesystem
This is not stored in /sys?
Is it truly important to store it more persistently?
>3) parallel operation on multiple filesystems where possible,
> but filesystems on a single physical device should
> run in serial (same as /sbin/fsck -A)
Should be quite trivial.
>4) some kind of config file in /etc/, parameters could include
> o) maximum run time, global and per filesystem
> o) run/dont run flag, global and per filesystem
Direction per run as well?
>Any thoughts? Shall I go ahead and write a first cut?
Please do, although I think it should be reimplemented in C sooner
or later, just to make sure it's an integral part of the reiser4progs
package :)
--
mjt
next prev parent reply other threads:[~2004-09-16 15:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-15 22:02 Benchmark : ext3 vs reiser4 and effects of fragmentation Will Smith
2004-09-16 8:52 ` Alex Zarochentsev
2004-09-16 13:08 ` mjt
2004-09-16 14:50 ` Will Smith
2004-09-16 15:03 ` mjt [this message]
2004-09-16 17:16 ` Hans Reiser
2004-09-16 15:38 ` Alex Zarochentsev
2004-09-16 15:52 ` mjt
2004-09-16 17:26 ` Hans Reiser
2004-09-16 18:38 ` Alex Zarochentsev
2004-09-16 19:00 ` mjt
2004-09-16 19:05 ` Chris Mason
2004-09-17 2:29 ` Hans Reiser
2004-09-17 17:01 ` Philippe Gramoullé
2004-09-16 15:38 ` Christian Mayrhuber
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=20040916150348.GL26192@nysv.org \
--to=mjt@nysv.org \
--cc=reiserfs-list@namesys.com \
--cc=will@willsmith.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 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.