From: ptb@lab.it.uc3m.es (Peter T. Breuer)
To: linux-raid@vger.kernel.org
Subject: Re: ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard)
Date: Tue, 4 Jan 2005 15:05:34 +0100 [thread overview]
Message-ID: <eekqa2-4m2.ln1@news.it.uc3m.es> (raw)
In-Reply-To: 200501041424.19802.maarten@ultratux.net
Maarten <maarten@ultratux.net> wrote:
> On Tuesday 04 January 2005 11:14, Peter T. Breuer wrote:
> > maarten <maarten@ultratux.net> wrote:
> > > On Monday 03 January 2005 21:41, Peter T. Breuer wrote:
> > > > maarten <maarten@ultratux.net> wrote:
>
> > It would make sense to a 16 year old, since that's about where you get
> > to be certified as competent in differential calculus and probability
> > theory, if my memory of my high school math courses is correct. This is
> > pre-university stuff by a looooooong way.
>
> Oh wow. So you deduced I did not study math at university ?
Well, I deduced that you did not get to the level expected of a 16 year
old.
> Well, that IS an eye-opener for me. I was unaware studying math was a
One doesn't "study" math, one _does_ math, just as one _does_ walking
down the street, talking, and opening fridge doors. Your competency
at it gets certified in school and uni, that's all.
> requirement to engage in conversation on the linux-raid mailinglist ?
Looks like it, or else one gets bogged down in inane conversations at
about the level of "what is an editor".
Look - a certain level of mathematical competence is required in the
technical world. You cannot get away without it. Being able to do math
to the level expected of an ordinary 16 year old is certainly expected
by me in order to be able to talk, walk, and eat pizza with you as an
ordinary human being.
As to the Poisson distribution, I know it forms part of the university
syllabus even for laboratory techs first degrees, because the head tech
here, who has been doing his degree in tech stuff here while he admins,
used to keep coming and asking me things like "how do I calculate the
expected time between two collisions given that packets are emitted
from both ends according to a Poisson distribution with mean mu".
And that's ordinary 16 year-old math stuff. Stands to reason they would
teach it in a university at a crummy place like this.
> Or is this not the list I think it is ?
It's not the list you think it is, I think.
> > The problem is that I never have a 9-year old child available when I
> > need one ...
>
> Um, check again... he's sitting right there with you I think.
OK! Now he can explain this man page to me, which they say a 9-year old
child can understand (must be the solaris man page for "passwd" again).
> > Therefore you forget it. All of differential calculus works like that.
> > Forget the square term - it vanishes. All terms of the series beyond
> > the first can be ignored as you go to the limiting situation.
>
> And that is precisely what false assumption you're making ! We ARE not going
There is no false assumption. This is "precisely" what you are getting
wrong. I do not want to argue with you, I just want you to GET IT.
> to the limiting situation.
Yes we are.
> We are discussing the probabilities in failures of
> media.
PER UNIT TIME, for gawd's sake. Choose a small unit. One small enough
to please you. Then make it "vanishingly small", slowly, please. Then
we can all take a rest while you get it.
> You cannot assume we will be talking about harddisks, and neither is
I don't.
> the failure rate in harddisk anywhere near limit zero.
Eh? It's tiny per tiny unit of time. As you would expect, naively.
> Drive manufacturers
> might want you to believe that through publishing highly theoretical MTBFs,
If the MTBF is one year (and we are not discussing failure, but error),
then the probability of a failure PER DAY is 1/365, or about 0.03. That
would make the square of that probability PER DAY about 0.0009, or
negligible in the scale of the linear term. This _is_ mathematics.
And if you want to consider the probability PER HOUR, then the
probability of failure is about 0.0012. Per minute it is about 0.00002.
Per second it is about 0.0000003. The square term is 0.0000000000009,
or completely negligible.
And that is failure, not error.
But we don't care. Just take a time unit that is pleasingly small, and
consider the probability per THAT unit. And please keep the unit to
yourself.
> but that doesn't make it so that any harddrive has a life expectancy of 20+
> years, as the daily facts prove all the time.
It does mean it. It means precisely that (given certain experimental
conditions). If you want to calculate the MTBF in a real dusty noisy
environment, I would say it is about ten years. That is, 10% chance of
failure per year.
If they say it is 20 years and not 10 years, well I believe that too,
but they must be keeping the monkeys out of the room.
> You cannot assume p to be vanishingly small.
I don't have to - make it so. Then yes, I can.
> Maybe p really is the failure
> rate in 20 year old DAT tapes that were stored at 40 degrees C. Maybe it is
You simply are spouting nonsense. Please cease. It is _painful_. Like
hearing somebody trying to sing when they cannot sing, or having to
admire amateur holiday movies.
P is vanishingly small when you make it so. Do so! It doesn't require
anything but a choice on your part to choose a sufficiently small unit
of time to scale it to.
> the failure rate of wet floppydisks. You cannot make assumptions about p.
I don't. You on the other hand ...
> The nice thing in math is that you can make great calculations when you
> assume a variable is limit zero or limit infinite. The bad thing is, you
Complete and utter bullshit. You ought to be ashamed.
> cannot assume that things in real life act like predefined math variables.
Rest of crank math removed. One can't reason with people who simply
don't have the wherewithal to recognise that the problem is inside
them.
Peter
next prev parent reply other threads:[~2005-01-04 14:05 UTC|newest]
Thread overview: 130+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200501030916.j039Gqe23568@inv.it.uc3m.es>
2005-01-03 10:17 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Guy
2005-01-03 11:31 ` Peter T. Breuer
2005-01-03 17:34 ` Guy
2005-01-03 19:20 ` ext3 Gordon Henderson
2005-01-03 19:47 ` ext3 Morten Sylvest Olsen
2005-01-03 20:05 ` ext3 Gordon Henderson
2005-01-03 17:46 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) maarten
2005-01-03 19:52 ` maarten
2005-01-03 20:41 ` Peter T. Breuer
2005-01-03 23:19 ` Peter T. Breuer
2005-01-03 23:46 ` Neil Brown
2005-01-04 0:28 ` Peter T. Breuer
2005-01-04 1:18 ` Alvin Oga
2005-01-04 4:29 ` Neil Brown
2005-01-04 8:43 ` Peter T. Breuer
2005-01-04 2:07 ` Neil Brown
2005-01-04 2:16 ` Ewan Grantham
2005-01-04 2:22 ` Neil Brown
2005-01-04 2:41 ` Andy Smith
2005-01-04 3:42 ` Neil Brown
2005-01-04 9:50 ` Peter T. Breuer
2005-01-04 14:15 ` David Greaves
2005-01-04 15:20 ` Peter T. Breuer
2005-01-04 16:42 ` Guy
2005-01-04 17:46 ` Peter T. Breuer
2005-01-04 9:30 ` Maarten
2005-01-04 10:18 ` Peter T. Breuer
2005-01-04 13:36 ` Maarten
2005-01-04 14:13 ` Peter T. Breuer
2005-01-04 19:22 ` maarten
2005-01-04 20:05 ` Peter T. Breuer
2005-01-04 21:38 ` Guy
2005-01-04 23:53 ` Peter T. Breuer
2005-01-05 0:58 ` Mikael Abrahamsson
2005-01-04 21:48 ` maarten
2005-01-04 23:14 ` Peter T. Breuer
2005-01-05 1:53 ` maarten
2005-01-04 9:46 ` Peter T. Breuer
2005-01-04 19:02 ` maarten
2005-01-04 19:12 ` David Greaves
2005-01-04 21:08 ` Peter T. Breuer
2005-01-04 22:02 ` Brad Campbell
2005-01-04 23:20 ` Peter T. Breuer
2005-01-05 5:44 ` Brad Campbell
2005-01-05 9:00 ` Peter T. Breuer
2005-01-05 9:14 ` Brad Campbell
2005-01-05 9:28 ` Peter T. Breuer
2005-01-05 9:43 ` Brad Campbell
2005-01-05 15:09 ` Guy
2005-01-05 15:52 ` maarten
2005-01-05 10:04 ` Andy Smith
2005-01-04 22:21 ` Neil Brown
2005-01-05 0:08 ` Peter T. Breuer
2005-01-04 22:29 ` Neil Brown
2005-01-05 0:19 ` Peter T. Breuer
2005-01-05 1:19 ` Jure Pe_ar
2005-01-05 2:29 ` Peter T. Breuer
2005-01-05 0:38 ` maarten
2005-01-04 9:40 ` Peter T. Breuer
2005-01-04 11:57 ` Which drive gets read in case of inconsistency? [was: ext3 journal on software raid etc] Michael Tokarev
2005-01-04 12:40 ` Morten Sylvest Olsen
2005-01-04 12:44 ` Peter T. Breuer
2005-01-04 14:22 ` Maarten
2005-01-04 14:56 ` Peter T. Breuer
2005-01-04 14:03 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) David Greaves
2005-01-04 14:07 ` Peter T. Breuer
2005-01-04 14:43 ` David Greaves
2005-01-04 15:12 ` Peter T. Breuer
2005-01-04 16:54 ` David Greaves
2005-01-04 17:42 ` Peter T. Breuer
2005-01-04 19:12 ` David Greaves
2005-01-04 0:45 ` maarten
2005-01-04 10:14 ` Peter T. Breuer
2005-01-04 13:24 ` Maarten
2005-01-04 14:05 ` Peter T. Breuer [this message]
2005-01-04 15:31 ` Maarten
2005-01-04 16:21 ` Peter T. Breuer
2005-01-04 20:55 ` maarten
2005-01-04 21:11 ` Peter T. Breuer
2005-01-04 21:38 ` Peter T. Breuer
2005-01-04 23:29 ` Guy
2005-01-04 19:57 ` Mikael Abrahamsson
2005-01-04 21:05 ` maarten
2005-01-04 21:26 ` Alvin Oga
2005-01-04 21:46 ` Guy
2005-01-03 20:22 ` Peter T. Breuer
2005-01-03 23:05 ` Guy
2005-01-04 0:08 ` maarten
2005-01-04 8:57 ` I'm glad I don't live in Spain (was Re: ext3 journal on software raid) David L. Smith-Uchida
2005-01-03 21:36 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Guy
2005-01-04 0:15 ` maarten
2005-01-04 11:21 ` Michael Tokarev
2005-01-03 9:30 Peter T. Breuer
-- strict thread matches above, loose matches on Subject: below --
2004-12-30 0:31 PROBLEM: Kernel 2.6.10 crashing repeatedly and hard Georg C. F. Greve
2004-12-30 16:23 ` Georg C. F. Greve
2004-12-30 17:39 ` Peter T. Breuer
2004-12-30 19:50 ` Michael Tokarev
2004-12-30 21:39 ` Peter T. Breuer
2005-01-02 19:42 ` ext3 journal on software raid (was Re: PROBLEM: Kernel 2.6.10 crashing repeatedly and hard) Andy Smith
2005-01-02 20:18 ` Peter T. Breuer
2005-01-03 0:30 ` Andy Smith
2005-01-03 6:41 ` Neil Brown
2005-01-03 8:37 ` Peter T. Breuer
2005-01-03 8:03 ` Peter T. Breuer
2005-01-03 8:58 ` Guy
2005-01-03 12:11 ` Michael Tokarev
2005-01-03 14:23 ` Peter T. Breuer
2005-01-03 18:30 ` maarten
2005-01-03 21:36 ` Michael Tokarev
2005-01-05 9:56 ` Andy Smith
2005-01-05 10:44 ` Alvin Oga
2005-01-05 10:56 ` Brad Campbell
2005-01-05 11:39 ` Alvin Oga
2005-01-05 12:02 ` Brad Campbell
2005-01-05 13:23 ` Alvin Oga
2005-01-05 13:33 ` Brad Campbell
2005-01-05 14:12 ` Erik Mouw
2005-01-05 14:37 ` Michael Tokarev
2005-01-05 17:11 ` Erik Mouw
2005-01-06 5:41 ` Brad Campbell
2005-01-05 15:17 ` Guy
2005-01-05 15:33 ` Alvin Oga
2005-01-05 16:22 ` Michael Tokarev
2005-01-05 17:23 ` Peter T. Breuer
2005-01-05 16:23 ` Andy Smith
2005-01-05 16:30 ` Andy Smith
2005-01-05 17:07 ` Guy
2005-01-05 17:21 ` Alvin Oga
2005-01-05 17:32 ` Guy
2005-01-05 18:37 ` Alvin Oga
2005-01-05 17:26 ` David Greaves
2005-01-05 18:16 ` Peter T. Breuer
2005-01-05 18:28 ` Guy
2005-01-05 18:26 ` Guy
2005-01-05 15:48 ` Peter T. Breuer
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=eekqa2-4m2.ln1@news.it.uc3m.es \
--to=ptb@lab.it.uc3m.es \
--cc=linux-raid@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;
as well as URLs for NNTP newsgroup(s).