From: Perry Kundert <perry.kundert@gmail.com>
To: Stefan Andersson <stefan@siwnet.net>
Cc: reiserfs-list@namesys.com
Subject: Re: Less disk space with reiser4?
Date: Wed, 13 Apr 2005 12:32:54 -0600 [thread overview]
Message-ID: <2f9ccaae05041311326ecd819c@mail.gmail.com> (raw)
In-Reply-To: <425D21A6.10001@siwnet.net>
On 4/13/05, Stefan Andersson <stefan@siwnet.net> wrote:
> Alex Zarochentsev wrote:
>
> >On Wed, Apr 13, 2005 at 02:51:13PM +0200, Stefan Andersson wrote:
> >
> >
> >>Thanks for all the answers.
> >>
> >>Now would it be possible to change the 5% to something else?
> >
> >even if the fs would be unreliable?
> >
> That is what I want to test, or if someone knows the answer to that.
>
I think claiming that the FS will become unreliable by choosing
some smaller amount of unused space, or making it a factor of total
RAM size instead of total File System size is a bit extreme...
There must be some theoretical maximum limit on the number of
dirty blocks that can possibly be outstanding -- and I suspect that it
is more related to the total amount of RAM available, and NOT related
to the total size of the filesystem. Proof:
1) The number of dirty blocks is NOT limited to the RAM available
2) That means that there exists a dirty block X, such that X is
considered dirty, but is not stored in available RAM
3) Reductio as Absurdium. Ergo, dirty blocks are limited to the
size of RAM.
Now, there may be further constraints -- a contiguous segment of
sectors must be available (unlikely), some dirty blocks may require
more than one block on disk be available (unlikely), or some dirty
blocks in RAM may implicitly dirty one or more (additional) blocks in
the filesystem.
Stilll, the "unused space" requirement would be constrained to
some multiple of RAM, NOT some percentage of the filesystem's size...
Just a guess; sorry if I'm missing something obvious...
--
-pjk
"If you will not fight when your victory will be sure and not too
costly, you may come to the moment when you will have to fight with
all the odds against you and only a precarious chance for survival.
There may even be a worse case. You may have to fight when there is no
hope of victory, because it is better to perish than to live as
slaves." -- Winston Churchill
next prev parent reply other threads:[~2005-04-13 18:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-11 14:30 Less disk space with reiser4? Stefan Andersson
2005-04-11 15:09 ` Łukasz Mierzwa
2005-04-11 19:52 ` Alex Zarochentsev
2005-04-11 20:22 ` Hans Reiser
2005-04-11 20:43 ` Chester R. Hosey
2005-04-12 0:57 ` David Masover
2005-04-13 12:51 ` Stefan Andersson
2005-04-13 13:04 ` Alex Zarochentsev
2005-04-13 13:41 ` Stefan Andersson
2005-04-13 18:32 ` Perry Kundert [this message]
2005-04-14 4:35 ` David Masover
2005-04-14 7:49 ` Alex Zarochentsev
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=2f9ccaae05041311326ecd819c@mail.gmail.com \
--to=perry.kundert@gmail.com \
--cc=perry@kundert.ca \
--cc=reiserfs-list@namesys.com \
--cc=stefan@siwnet.net \
/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.