From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: tridge@samba.org
Cc: Pavel Machek <pavel@ucw.cz>,
Rusty Russell <rusty@rustcorp.com.au>,
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
john.lanza@linux.com, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org,
Dave Kleikamp <shaggy@linux.vnet.ibm.com>,
Steve French <sfrench@us.ibm.com>, Mingming Cao <cmm@us.ibm.com>
Subject: Re: [PATCH] Added CONFIG_VFAT_FS_DUALNAMES option
Date: Wed, 8 Jul 2009 16:59:37 -0700 [thread overview]
Message-ID: <20090708235937.GA20837@linux.vnet.ibm.com> (raw)
In-Reply-To: <20090708221413.GH15111@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 7283 bytes --]
On Wed, Jul 08, 2009 at 03:14:13PM -0700, Paul E. McKenney wrote:
> On Thu, Jul 09, 2009 at 07:42:27AM +1000, tridge@samba.org wrote:
> > Hi Paul,
> >
> > These probabilities are way off. They assume that whatever interaction
> > happens in XP has infinite memory. The testing I've done indicates
> > that the memory for this interaction is very small (maybe 3 or 4? it's
> > hard to know precisely).
>
> Good to know! I will rework assuming that the memory is 4, let me
> know if you learn more.
>
> > I've also confirmed this with lots of testing. If the probability was
> > 39% for any directory size then I would have found it.
>
> This new information will likely reduce the predicted probability of
> bluescreen by several orders of magnitude for large directories. Not
> that much effect for small directories, but not a real issue given
> how low the probabilities are to begin with.
>
> > In all my testing I did not once produce a XP crash with the full
> > patch. To produce the XP crash I needed to have a reduced version of
> > the patch with less randomness.
>
> Well, let's see if I can produce a reasonably realistic model. :-)
> (I knew I should have gotten more sleep last night!!!)
This model assumes a finite memory, so that at least two files out of
a group of "l" recently opened files have to collide to result in a
bluescreen. I don't trust it yet, but thought I should give people a
chance to poke holes in it.
Thanx, Paul
------------------------------------------------------------------------
Results
Assuming the worst case where the user opens each file in the directory
of interest, the probability depends on the number of long-named files
in the given directory as follows (derivation at EOM):
Files Probability Odds
----- -------------------- -------
32767 9.15401625433259b-5 (1 in 11,000)
16384 4.576973184985319b-5 (1 in 22,000)
8192 2.288233388567135b-5 (1 in 44,000)
4096 1.143843845796893b-5 (1 in 87,000)
2048 5.716441632059139b-6 (1 in 170,000)
1024 2.855430941007629b-6 (1 in 350,000)
512 1.424922525947476b-6 (1 in 700,000)
256 7.096675510325187b-7 (1 in 1,400,000)
128 3.520398717286601b-7 (1 in 2,800,000)
64 1.732259841151157b-7 (1 in 5,800,000)
32 8.381902831793723b-8 (1 in 12,000,000)
16 3.911554742174612b-8 (1 in 26,000,000)
8 1.676380622425006b-8 (1 in 60,000,000)
4 5.587935438151892b-9 (1 in 179,000,000)
2 9.313225746154785b-10 (1 in 1,000,000,000)
1 0.0b0
This is for 2^32 random values per entry and a WinXP "memory" of four
entries.
------------------------------------------------------------------------
Derivation:
o The patch uses 6 random bytes, with 6 bits each, for
32^6 = 1,073,741,824 possible combinations. (Based on code
in vfat_build_dummy_83_buffer() in the patch Tridge posted on
June 27th.)
o There are a maximum of 32,767 entries in a VFAT directory.
o In the worst case, the user application will open each and
every file in the directory. WinXP seems to have a limited
memory for recently opened files, and we assume that once this
memory is full, opening a new file causes one of the recently
opened files to be forgotten. The size of its memory appears
to be in the range of 3-4 based on Tridge's testing, so we
will assume the worst case (4) and parameterize with l=4.
o As noted earlier, the probability the infamous Birthday Paradox
is given by:
P(n, m) = (n-1)! / ((n-m)! * n^(m-1))
Here "n" is the number of possible birthdays (1,073,741,824 in
this case) and "m" is the number of people (32,767 in this case).
P(n, m) is the probability of -no- common birthday. This is not
the probability of no bluescreen, but we will use this result
to calculate this probability while initially filling WinXP's
memory. I again use maxima, and again use the optimized form
based on the binomial function:
b(n,m):=binomial(n,m)*m!/n^m;
o See the attached .eps...
o The probability of no bluescreen while opening the first "l"
files is given by b(n,l), just as before.
o Given no bluescreen while opening the first "l" files, the
probability of no bluescreen while opening the "l+1"st file
is the probability of missing the "l-1" files that remain
after ejecting one of them to make room is "(n-l+1)/n".
The cumulative probability of no bluescreen is thus:
P(n,m,l) = b(n,l)*(n-l+1)/n
o We have the same situation when opening the "l+2"nd file,
the probability of no bluescreen is again "(n-l+1)/n".
o This situation will repeat "m-l" times, so that we have:
P(n,m,l) = b(n,l)*((n-l+1)/n)^(m-l)
In maxima-speak:
b(n,m):=binomial(n,m)*m!/n^m;
nbs(n,m,l):=b(n,l)*((n-l+1)/n)^(m-l);
The probability of bluescreening when faced with 32767 files
in a directory, 32^6 possible random values, and the capacity
to remember four files is then:
1-nbs(32^6,32767,4);
For floating-point results instead of a massive fraction:
bfloat(1-nbs(32^6,32767,4));
See below for the actual maxima output, typos and all.
------------------------------------------------------------------------
maxima
paulmck@paulmck-laptop:~$ maxima
Maxima 5.12.0 http://maxima.sourceforge.net
Using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (aka GCL)
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
This is a development version of Maxima. The function bug_report()
provides bug reporting information.
(%i1) b(n,m):=binomial(n,m)*m!/n^m;
binomial(n, m) m!
(%o1) b(n, m) := -----------------
m
n
(%i2) nbs(n,m,l):=b(n,l)*((n-l+1)/n)^(m-l);
n - l + 1 m - l
(%o2) nbs(n, m, l) := b(n, l) (---------)
n
(%i3) bfloat(1-nbs(32^6,32767,4));
(%o3) 9.15401625433259b-5
(%i4) bfloat(1-nbs(32^6,2^14,4));
(%o4) 4.576973184985319b-5
(%i5) bfloat(1-nbs(32^6,2^13,4));
(%o5) 2.288233388567135b-5
(%i6) bfloat(1-nbs(32^6,2^12,4));
(%o6) 1.143843845796893b-5
(%i7) bfloat(1-nbs(32^6,2^11,4));
(%o7) 5.716441632059139b-6
(%i8) bfloat(1-nbs(32^6,2^10,4));
(%o8) 2.855430941007629b-6
(%i9) bfloat(1-nbs(32^6,2^9,4));
(%o9) 1.424922525947476b-6
(%i10) bfloat(1-nbs(32^6,2^8,4));
(%o10) 7.096675510325187b-7
(%i11) bfloat(1-nbs(32^6,2^7,4));
(%o11) 3.520398717286601b-7
(%i12) bfloat(1-nbs(32^6,2^6,4));
(%o12) 1.732259841151157b-7
(%i13) bfloat(1-nbs(32^6,2^5,4));
(%o13) 8.381902831793723b-8
(%i14) bfloat(1-nbs(32^6,2^4,4));
(%o14) 3.911554742174612b-8
(%i15) bfloat(1-nbs(32^6,2^3,4));
(%o15) 1.676380622425006b-8
(%i16) bfloat(1-nbs(32^6,2^2,4));
(%o16) 5.587935438151892b-9
(%i17) bfloat(1-nbs(32^6,2^1,4));
(%o17) - 1.734723480823569b-18
(%i18) bfloat(1-b(32^6,2));
(%o18) 9.313225746154785b-10
(%i19) bfloat(1-b(32^6,1));
(%o19) 0.0b0
[-- Attachment #2: WinXPmodel.eps --]
[-- Type: application/postscript, Size: 8861 bytes --]
next prev parent reply other threads:[~2009-07-08 23:59 UTC|newest]
Thread overview: 194+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-26 19:19 [PATCH] Added CONFIG_VFAT_FS_DUALNAMES option tridge
2009-06-26 21:40 ` H. Peter Anvin
2009-06-26 22:21 ` tridge
2009-06-27 1:48 ` OGAWA Hirofumi
2009-06-27 17:26 ` Jan Engelhardt
2009-06-27 1:56 ` OGAWA Hirofumi
2009-06-27 17:21 ` Jan Engelhardt
2009-06-28 2:59 ` tridge
2009-06-28 21:57 ` Jamie Lokier
2009-06-28 22:02 ` Jan Engelhardt
2009-06-28 22:05 ` Jamie Lokier
2009-06-29 1:23 ` tridge
2009-06-28 1:54 ` Eric W. Biederman
2009-06-28 2:19 ` tridge
2009-06-28 4:10 ` Eric W. Biederman
2009-06-28 5:38 ` tridge
2009-06-28 6:25 ` OGAWA Hirofumi
2009-06-28 19:51 ` Eric W. Biederman
2009-06-28 20:13 ` James Bottomley
2009-06-28 20:45 ` Eric W. Biederman
2009-06-28 21:45 ` James Bottomley
2009-06-28 21:28 ` tridge
2009-06-29 1:30 ` tridge
2009-06-29 22:18 ` Greg KH
2009-06-29 22:42 ` tridge
2009-06-29 22:52 ` Greg KH
2009-06-29 23:36 ` OGAWA Hirofumi
2009-06-29 23:51 ` tridge
2009-06-30 0:55 ` OGAWA Hirofumi
2009-06-30 6:31 ` Pavel Machek
2009-07-01 10:09 ` Alan Cox
2009-07-01 11:11 ` tridge
2009-07-01 11:34 ` Alan Cox
2009-07-01 10:49 ` Rusty Russell
2009-07-01 11:25 ` Alan Cox
2009-07-01 14:05 ` Theodore Tso
2009-07-01 14:17 ` Alan Cox
2009-07-02 1:42 ` tridge
2009-07-02 10:33 ` Alan Cox
2009-07-02 12:43 ` tridge
2009-07-02 21:49 ` Pavel Machek
2009-07-06 19:57 ` Jamie Lokier
2009-07-01 16:18 ` Stefan Richter
2009-07-02 23:17 ` CONFIG_VFAT_FS_DUALNAMES regression Jan Engelhardt
2009-07-02 23:37 ` tridge
2009-07-03 0:11 ` Jan Engelhardt
2009-07-03 0:25 ` tridge
2009-07-03 1:10 ` Jan Engelhardt
2009-07-03 1:26 ` tridge
2009-07-03 1:58 ` Jan Engelhardt
2009-07-11 0:14 ` Jamie Lokier
2009-07-02 23:46 ` CONFIG_VFAT_FS_DUALNAMES regressions Jan Engelhardt
2009-07-03 0:14 ` tridge
2009-07-03 0:58 ` OGAWA Hirofumi
2009-07-03 1:11 ` tridge
2009-07-03 1:50 ` Jan Engelhardt
2009-07-03 1:59 ` tridge
2009-07-03 2:09 ` Jan Engelhardt
2009-07-03 3:25 ` tridge
2009-07-03 6:46 ` OGAWA Hirofumi
2009-07-03 9:40 ` Jan Engelhardt
2009-07-03 12:24 ` tridge
2009-07-04 3:09 ` OGAWA Hirofumi
2009-07-06 11:40 ` Jan Engelhardt
2009-07-06 13:05 ` tridge
2009-07-06 16:17 ` David Newall
2009-07-06 19:33 ` Jamie Lokier
2009-07-06 18:55 ` Jan Engelhardt
2009-07-06 20:26 ` tridge
2009-07-06 20:42 ` Jan Engelhardt
2009-07-08 7:31 ` tridge
2009-07-06 20:36 ` Jan Engelhardt
2009-07-06 20:58 ` Jamie Lokier
2009-07-06 21:08 ` Jan Engelhardt
2009-07-06 22:24 ` Jamie Lokier
2009-07-07 9:36 ` Jan Engelhardt
2009-07-07 0:21 ` tridge
2009-07-07 21:56 ` Martin Steigerwald
2009-07-07 22:09 ` Martin Steigerwald
2009-07-08 3:12 ` tridge
2009-07-08 10:04 ` Alan Cox
2009-07-08 10:48 ` tridge
2009-07-08 12:02 ` Alan Cox
2009-07-08 13:02 ` tridge
2009-07-08 13:25 ` Alan Cox
2009-07-09 1:20 ` tridge
2009-07-09 9:42 ` Alan Cox
2009-07-09 13:59 ` James Bottomley
2009-07-09 14:10 ` Alan Cox
2009-07-09 15:25 ` Theodore Tso
[not found] ` <20090709171501.GA2991@infradead.org>
2009-07-09 20:57 ` David Newall
2009-07-09 22:23 ` Martin Steigerwald
2009-07-10 1:45 ` David Newall
2009-07-10 18:49 ` Martin Steigerwald
2009-07-10 19:31 ` Jonathan Corbet
2009-07-10 20:40 ` Bartlomiej Zolnierkiewicz
2009-07-12 11:21 ` Jörn Engel
2009-07-12 11:27 ` Jan Engelhardt
2009-07-13 22:20 ` Jamie Lokier
2009-07-13 22:32 ` Jan Engelhardt
2009-07-10 21:14 ` Alan Cox
2009-07-12 8:52 ` David Newall
2009-07-10 0:09 ` Alan Cox
2009-07-08 12:23 ` Jan Engelhardt
2009-07-08 15:27 ` James Bottomley
2009-07-08 15:37 ` Alan Cox
2009-07-08 16:06 ` James Bottomley
2009-07-08 16:18 ` Alan Cox
2009-07-09 4:25 ` tridge
2009-07-09 5:27 ` OGAWA Hirofumi
2009-07-09 7:21 ` Pavel Machek
2009-07-09 7:34 ` David Newall
2009-07-09 9:51 ` Alan Cox
2009-07-09 4:53 ` OGAWA Hirofumi
2009-07-09 9:53 ` Alan Cox
2009-07-12 19:39 ` OGAWA Hirofumi
2009-07-21 3:37 ` tridge
2009-07-21 9:16 ` Boaz Harrosh
2009-07-21 10:31 ` Pavel Machek
2009-07-21 13:24 ` tridge
2009-07-21 15:08 ` John Lanza
2009-07-21 19:36 ` John Lanza
2009-07-21 21:37 ` Pavel Machek
2009-07-21 22:38 ` tridge
2009-07-21 10:44 ` Jan Engelhardt
2009-07-21 13:04 ` tridge
2009-07-21 15:06 ` John Lanza
2009-07-21 19:38 ` John Lanza
2009-07-21 10:31 ` Pavel Machek
2009-07-21 13:19 ` tridge
2009-08-08 12:19 ` Pavel Machek
2009-07-08 11:39 ` Martin Steigerwald
2009-07-08 13:53 ` Jamie Lokier
2009-07-08 17:12 ` Jeremy Allison
2009-07-09 3:23 ` tridge
2009-07-09 13:34 ` Martin Steigerwald
2009-07-09 4:13 ` tridge
2009-07-09 19:47 ` Martin Steigerwald
2009-07-10 7:36 ` Pavel Machek
2009-07-10 21:12 ` Jamie Lokier
2009-07-10 21:28 ` Jamie Lokier
2009-07-11 2:03 ` Jamie Lokier
2009-07-07 19:51 ` Pavel Machek
2009-07-08 7:42 ` tridge
2009-07-08 10:27 ` Jan Engelhardt
2009-07-09 2:23 ` tridge
2009-07-09 8:24 ` Jan Engelhardt
2009-07-10 7:35 ` Pavel Machek
2009-07-06 20:04 ` Jamie Lokier
2009-07-08 7:30 ` tridge
2009-07-10 21:44 ` Jamie Lokier
2009-07-02 0:34 ` [PATCH] Added CONFIG_VFAT_FS_DUALNAMES option Rusty Russell
2009-07-02 21:46 ` Pavel Machek
2009-07-02 22:06 ` tridge
2009-07-02 22:33 ` Pavel Machek
2009-07-02 22:41 ` tridge
2009-07-02 22:44 ` Pavel Machek
2009-07-02 23:59 ` tridge
2009-07-08 9:21 ` Pavel Machek
2009-07-08 14:25 ` Paul E. McKenney
2009-07-08 21:42 ` tridge
2009-07-08 22:14 ` Paul E. McKenney
2009-07-08 23:59 ` Paul E. McKenney [this message]
2009-07-08 16:46 ` H. Peter Anvin
2009-07-03 0:03 ` Rusty Russell
2009-07-02 23:55 ` Rusty Russell
2009-07-01 10:50 ` tridge
2009-07-01 11:31 ` Alan Cox
2009-07-01 13:16 ` tridge
2009-07-01 13:38 ` Alan Cox
2009-07-01 14:02 ` tridge
2009-07-01 14:41 ` Alan Cox
2009-07-02 4:04 ` tridge
2009-07-02 10:32 ` Alan Cox
2009-07-02 12:38 ` tridge
2009-07-02 16:56 ` Alan Cox
2009-07-03 2:50 ` OGAWA Hirofumi
2009-07-02 14:56 ` James Bottomley
2009-07-02 15:27 ` Theodore Tso
2009-07-02 18:12 ` Alan Cox
2009-07-02 21:25 ` James Bottomley
2009-07-01 11:48 ` Boaz Harrosh
2009-07-01 12:28 ` tridge
2009-07-01 15:44 ` James Bottomley
2009-07-02 22:03 ` Pavel Machek
2009-07-06 20:41 ` Jamie Lokier
2009-07-07 10:02 ` Boaz Harrosh
2009-07-07 11:25 ` Jamie Lokier
2009-07-07 11:48 ` Boaz Harrosh
2009-07-07 11:50 ` tridge
2009-07-02 22:00 ` Pavel Machek
2009-07-02 22:23 ` tridge
2009-07-02 22:41 ` Pavel Machek
[not found] <4bbed3f70907082014t643209eaw5fc7cd7297f7af78@mail.gmail.com>
2009-07-09 13:16 ` John Lanza
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=20090708235937.GA20837@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=cmm@us.ibm.com \
--cc=hirofumi@mail.parknet.co.jp \
--cc=john.lanza@linux.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rusty@rustcorp.com.au \
--cc=sfrench@us.ibm.com \
--cc=shaggy@linux.vnet.ibm.com \
--cc=tridge@samba.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).