From: Hans Reiser <reiser@namesys.com>
To: Will Smith <will@willsmith.org>
Cc: "Markus Törnqvist" <mjt@nysv.org>, reiserfs-list@namesys.com
Subject: Re: Benchmark : ext3 vs reiser4 and effects of fragmentation.
Date: Thu, 16 Sep 2004 10:16:04 -0700 [thread overview]
Message-ID: <4149CA54.80901@namesys.com> (raw)
In-Reply-To: <4149A843.7010804@willsmith.org>
Well, I am going to try being honest and see what happens.
I am more than 170k in debt, and Namesys is doing badly fiscally. A
technical great success being stabilized now, but then there is my
ongoing fiscal disaster. Once again, we are missing payroll. My wife
is divorcing me in part because I keep going deeper into debt, and I
thank her for divorcing me now rather than later. Unfortunately she is
making the divorce messy enough to keep me from pulling Namesys out of
the fiscal tailspin by consuming all my time with things like proving I
am not making the fantastic amounts of money she claims I am. I hope
next month is better.
The consistent tendency of large corporations to buy service contracts
only for proprietary software and not buy it for free software of equal
importance to their business is decisive in making our business not
viable fiscally. Knowing that it is irrational of them economically
does not keep me in business.
So we need something to entice them into cutting a check, to which they
can then add support. At the same time we want to avoid harming users
who cannot pay, or who don't care enough about the FS to bother to pay.
The repacker/resizer seems perfect for that. Nobody has to have it, and
yet sysadmins of large corporations will pay for it. I want them to pay
5% of their storage hardware costs, which means disk drives plus raid
cards, and if the machine is primarily a file server it means the whole
computer. For this they get a resizer, a repacker, and priority
support, with cell phone numbers of developers if they pay more than $1000.
I keep experimenting with open source business models, trying to make
them work. One of the possibilities for us is a blended model, in which
all the essentials are free, and the fripperies are for a fee.
There is nothing less essential than an online repacker/resizer. Yet it
is desirable enough to pay for.
Reiser4 without an online repacker/resizer is better than ext3 by a
lot. The money from the repacker will help us increase that lead
further. An online repacker/resizer could pay for the semantic
enhancements that are really important to users, and could allow us to
make those free. I am worried that because of finances we are not
going to beat WinFS to market when we otherwise could have done so.
Money is like food. The difference between a fine restaurant, and just
having a full refridgerator with ordinary vegetables and meat, is not a
lot. The difference between a full refridgerator and an empty one is a lot.
Charity is best if made a part time job of, not because men need money,
but because families need money, and men need to fulfill that obligation
well enough that the refridgerator is full.
Hans
PS
We need to have a better understanding of why reiser4 is not doing a
good enough job with just allocation on flush. I suspect it should be
doing better. Next month I hope to be able to take the time to look
into it. I am spending all of my time dealing with divorce and money
issues and the code is just going unsupervised, sigh....
Will Smith wrote:
>
> Markus Törnqvist wrote:
>
>>> yes, we had similar results. it is so cool that reiser4 repacker
>>> effect
>>> is visible outside namesys :)
>>
>>
>> S'cuse me, but why does it have to be run several times?
>
>
> I don't pretend to know the maths/logic of why, but from the reiser4
> description (http://www.namesys.com/v4/v4.html#repacker)
>
> "This repacker goes through the entire tree ordering, from left to
> right and then from right to left, alternating each time it runs."
>
> "In the absence of FS activity the effect of this over time is to sort
> by tree order (defragment), and to pack with perfect efficiency."
>
>
> My testing showed that this is indeed the case -
>
> If I ran the repacker once (say left to right), the fragmentation was
> not fully reduced.
>
> If I ran the repacker several times (left->right, right->left, and
> repeat) then fragmentation fell down to almost 0.
>
>
> Userspace Tool for Repacker
> ----------------------------
>
> I take it from an earlier comment by Hans that the repacker is not
> intended to be used yet? If it is indeed ready for primetime,
> is anybody working on userspace tools
> (/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.
>
> My proposed design specs would include:
>
> 1) runs in /etc/cron.daily near the end (since cron causes lots of
> disk activity)
> 2) the last-run-direction should be persistently stored per filesystem
> 3) parallel operation on multiple filesystems where possible,
> but filesystems on a single physical device should
> run in serial (same as /sbin/fsck -A)
> 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
>
>
> Any thoughts? Shall I go ahead and write a first cut?
>
>
>
> Will Smith
>
>
>
>
>
>
>
next prev parent reply other threads:[~2004-09-16 17:16 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
2004-09-16 17:16 ` Hans Reiser [this message]
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=4149CA54.80901@namesys.com \
--to=reiser@namesys.com \
--cc=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.