From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: tridge@samba.org, 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 07:25:20 -0700 [thread overview]
Message-ID: <20090708142520.GA7817@linux.vnet.ibm.com> (raw)
In-Reply-To: <20090708092133.GC24385@elf.ucw.cz>
On Wed, Jul 08, 2009 at 11:21:33AM +0200, Pavel Machek wrote:
> On Fri 2009-07-03 09:59:35, tridge@samba.org wrote:
> > Hi Pavel,
> >
> > > That's why we have ethernet checksums.
> >
> > which of course just changes the number of bits. The argument remains
> > the same.
>
> Ok, so what is your estimate of XP crash probability?
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 3.934446601778345b-1 (39.3%)
16384 1.174969255061134b-1 (11.7%)
8192 3.076314519945223b-2 ( 3.1%)
4096 7.780179085651447b-3 ( 0.8%)
2048 1.950268317016874b-3 ( 0.2%)
1024 4.87685610530225b-4 (1 in 2,000)
512 1.218244920604881b-4 (1 in 8,000)
256 3.039790922077076b-5 (1 in 30,000)
128 7.569761535306629b-6 (1 in 100,000)
64 1.877544584847826b-6 (1 in 500,000)
32 4.61935894834079b-7 (1 in 2,000,000)
16 1.117587032466174b-7 (1 in 9,000,000)
8 2.607703180994292b-8 (1 in 38,000,000)
4 5.587935438151892b-9 (1 in 180,000,000)
2 9.313225746154785b-10 (1 in 1,000,000,000)
1 0.0b0
The number of files that people keep in a given directory will vary,
but in my admittedly limited experience, most people tend towards the
low end of this range. What number of files per directory do you see
on embedded-device memory sticks?
Furthermore, this assumes that the user actually opens each and every file
in the directory. If the user keeps (say) 1024 files in the directory,
but only opens two of them on any given memory-stick insertion, then
the odds are one in a billion rather than one in two thousand.
[Tridge -- isn't this only for subdirectories? Or can collisions in
the root directory also result in WinXP bluescreens?]
> > > It already _was_ perfect before you started patching it.
> >
> > wow, I really didn't expect the objection to my patch to be that VFAT
> > is perfect!
>
> But ... it was, and there is still possibility of just using position
> in directory to avoid collisions completely.
Almost. The imperfection comes from the fact that storage media are not
totally reliable, so that given enough uses of large enough numbers of
memory sticks, there will eventually be a WinXP bluescreen. Please note
that people really have reported this WinXP bug.
Thanx, Paul
------------------------------------------------------------------------
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. I don't have any information on
whether WinXP has a limited memory for recently open files.
I therefore assume the worst case, namely that WinXP remembers
every file that it has opened.
o As noted in this thread, the probability of bluescreen is
given by the infamous Birthday Paradox:
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, so the
probability of WinXP bluescreen is 1-P(n,m).
Because I don't want to worry about round-off error, I use the
arbitrary-precision arithmetic in the "maxima" symbolic-math
package, which is related to the fabled Macsyma project. However,
computing the factorials without cancellation takes too long,
so we transform the factorials into the binomial function, which
has a highly optimized maxima implementation. The equivalent
but more efficient representation is as follows:
b(n,m):=binomial(n,m)*m!/n^m;
Then 1-b(32^6,32767) gives the exact probability of bluescreen
on a maximal-sized directory, which is the ratio of a pair of
extremely large integers. More usefully, bfloat(1-b(32^6,32767))
gives an approximation in scientific notation. (Don't forget
the trailing semicolon that maxima requires.)
Computing bfloat(1-b(32^6,32767)) takes about 70 seconds on my
2GHz x86 laptop.
See below for the actual maxima output, typos and all.
------------------------------------------------------------------------
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) bfloat(1-b(32^6,32767));
(%o2) 3.934446601778345b-1
(%i3) bfloat(1-b(32^6,2^14));
(%o3) 1.174969255061134b-1
(%i4) bfloat(1-b(32^6,2^13));
(%o4) 3.076314519945223b-2
(%i5) bfloat(1-b(32^6,2^12));
(%o5) 7.780179085651447b-3
(%i6) bfloat(1-b(32^6,2^11));
(%o6) 1.950268317016874b-3
(%i7) bfloat(1-b(32^6,2^10));
(%o7) 4.87685610530225b-4
(%i8) bfloat(1-b(32^6,2^9));
(%o8) 1.218244920604881b-4
(%i9) bfloat(1-b(32^6,2^8));
(%o9) 3.039790922077076b-5
(%i10) bfloat(1-b(32^6,2^7));
(%o10) 7.569761535306629b-6
(%i11) bfloat(1-b(32^6,2^6));
(%o11) 1.877544584847826b-6
(%i12) bfloat(1-b(32^6,2^));
Incorrect syntax: Illegal use of delimiter )
bfloat(1-b(32^6,2^)
^
(%i12) bfloat(1-b(32^6,2^5));
(%o12) 4.61935894834079b-7
(%i13) bfloat(1-b(32^6,2^4));
(%o13) 1.117587032466174b-7
(%i14) bfloat(1-b(32^6,2^3));
(%o14) 2.607703180994292b-8
(%i15) bfloat(1-b(32^6,2^2));
(%o15) 5.587935438151892b-9
(%i16) bfloat(1-b(32^6,2^1));
(%o16) 9.313225746154785b-10
(%i17) bfloat(1-b(32^6,2^0));
(%o17) 0.0b0
(%i18)
next prev parent reply other threads:[~2009-07-08 14:25 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 [this message]
2009-07-08 21:42 ` tridge
2009-07-08 22:14 ` Paul E. McKenney
2009-07-08 23:59 ` Paul E. McKenney
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=20090708142520.GA7817@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).