On Sun, 9 Feb 2003, Rahul Siddharthan wrote:
> (I assume I'm replying to the "real" PHK here)
> [EMAIL PROTECTED] wrote:
> > We know that the lamer behind the Troll is "Bill Huey" aka "billh".
>
> Is there any evidence for it? If so, you should share it and if not,
> you shouldn't make such accusa
[follow-ups to [EMAIL PROTECTED], please]
On Fri, 24 Jan 2003, Josef El-Rayes wrote:
> as you can see your questions are not very welcome on the mailinglists,
> therefore i advice you to have a look at this book if you are interested
> in BSD's technical background
There is one mailing list wher
On Tue, 20 Aug 2002, Mosko Bilekic wrote:
> Gentlemen, it's time to explain why FreeBSD is such a
> failure.
Maybe it's because the developers prefer to spend their
time and energy on gossip instead of technical issues ?
No wait, those aren't the developers, can't be. Please
tell me those aren'
On Sat, 29 Sep 2001, Alfred Perlstein wrote:
> * Vladimir Dozen <[EMAIL PROTECTED]> [010929 14:38] wrote:
>
> > P.S. Anyway, I do NOT insist my solution is better, and even that it
> > is good for anything at all. It was fun for me to hack in BSD kernel,
> > and it was interesting challe
On Sat, 29 Sep 2001, Vladimir Dozen wrote:
> I have wrote a patch that modifies behaivour (have I spelled this
> word right? ;) of VM when we are out of memory. Instead of killing
> largest process, we remap parts of it's address space onto temporal
> files (exactly as HP-UX does when swa
On Tue, 21 Aug 2001, Terry Lambert wrote:
> Peter Wemm wrote:
> > No. I have a machine with 6GB in it waiting for finishing the PAE
> > tweaks.
>
> Are you actually going ahead with the PAE support?
>
> Will this be a compile-time option, so that it can be
> turned off?
It better be because the t
On Sun, 19 Aug 2001, Matt Dillon wrote:
> : Uh, I don't think you understand what this limit is about. It's
> :essentially the limit on the amount of filesystem directory data that
> :can be cached. It does not limit the amount of file data that can
> :be cached - that is only limited by the am
On Sun, 19 Aug 2001, Matt Dillon wrote:
> In FreeBSD land the use-case would simply be our physical-backed-shared-
> memory feature. We could implement the 8-byte MMU extensions in the
> PMAP code as a kernrel option to be able to access ram > 4GB without
> having to change anyth
On Sat, 18 Aug 2001, Leo Bicknell wrote:
> On Sat, Aug 18, 2001 at 06:34:43PM -0700, Peter Wemm wrote:
> > No. I have a machine with 6GB in it waiting for finishing the PAE
> > tweaks.
> >
> > Intel ppro, pentium2 and pentium3 has a maximum RAM of 64GB. Pentium4 may
> > have more but I have not c
On Wed, 8 Aug 2001, craig wrote:
> I think the performance is the most important in kernel, other
> thing is second. I remember in linux linear address is real
> physical address in kernel space(is it true?). Why freebsd does
> not do in the same way?
1) wouldn't you think things like reliabilit
On Tue, 7 Aug 2001, Terry Lambert wrote:
> Matt Dillon wrote:
> > All the cpu's don't get the interrupt, only one does.
>
> I think that you will end up taking an IPI (Inter Processor
> Interrupt) to shoot down the cache line during an invalidate
> cycle, when moving an interrupt processing t
On Sun, 5 Aug 2001, Garance A Drosihn wrote:
> Basically, it was just a quick swapping mechanism. In the
> context of IA-32, you could maybe have the first gigabyte of
> space as "fixed", and the remaining three gigabytes as multiple
> ("named") address spaces. Each named-address space could be
On Fri, 3 Aug 2001, Terry Lambert wrote:
> You still haven't told me what Linux does for 2x4G processes
> and a 1G kernel with "only" 8G of physical RAM. I rather
> suspect that as soon as your usage exceeds real memory, it
> all goes to hell very quickly, since your L1 and L2 caches
> are effec
On Thu, 2 Aug 2001, Kenneth Wayne Culver wrote:
"Replying above an email because the curser is there is like
shitting in your pants because your ass is there when you
need to go to the toilet."
> BUT, don't the motherboards also have to support this? And isn't
> it only supported through some
On Thu, 2 Aug 2001, Kenneth Wayne Culver wrote:
> Also, the PIII CAN'T natively support more than 4GB of ram. If a
> particular PIII motherboard supports this, then it's using some
> kind of wierd chipset that allows this to happen. 4GB is the
> limit with a 32 bit chip I believe; and the PIII is
On Thu, 2 Aug 2001, Terry Lambert wrote:
> Correct me if I'm wrong, and 64 bit PCI cards can in fact
> DMA at offsets above 4G, in the physical address space...
They can. And for 32 bit PCI cards you simply use
bounce buffers in the same way you handle ISA bounce
buffers.
It's ugly, but if you
On Thu, 2 Aug 2001, Terry Lambert wrote:
> Original poster said he was working on it for Linux, which
> means it's not done, which means "not Linux".
It's been running for a while now, integrated
in the 2.4 kernel.
The way Linux manages to avoid the horrors you
describe is by simply not letting
On Thu, 2 Aug 2001, Terry Lambert wrote:
> Rik van Riel wrote:
> > > > Only if you want to use it all within one process.
> > >
> > > No. It still bites you if you want to do IPC, etc., since you
> > > can not guarantee the structures used for this are
On Thu, 2 Aug 2001, mark tinguely wrote:
> The addressing use 64 bits for a memory pointer and the additional
> page indirection add to the overhead. The stickler is the MMU is
> still 32 bits. This means the PAE must segment the 64GB space into
> 4GB segments or 4 1GB segments. The OS must manag
On Thu, 2 Aug 2001, Charles Randall wrote:
> From: Terry Lambert [mailto:[EMAIL PROTECTED]]
> >I have yet to see one person using it for anything. So far,
> >it is nothing more than marketing fodder: I haven't seen one
> >motherboard capable of more than 4G worth of SIMMs.
>
> The Dell PowerEdge
On Thu, 2 Aug 2001, Julian Elischer wrote:
> On Thu, 2 Aug 2001, Rik van Riel wrote:
> >
> > On the really large machines, this can lead to the
> > situation where even the page tables hardly fit into
> > KVA. 4MB pages seem like the only solution ...
>
> There
On Wed, 1 Aug 2001, Mike Smith wrote:
> > I know PIII can support 64G physical memory. In FreeBSD how can I visit
> > such range memory(4G-64G) ?
>
> You can't. Those memory ranges are strictly off-limits to
> non-US citizens.
And under the DMCA, US citizens aren't allowed to build
or distribut
On Wed, 1 Aug 2001, Terry Lambert wrote:
> > craig wrote:
> >
> >
> > I know PIII can support 64G physical memory. In FreeBSD how can I visit such
> > range memory(4G-64G) ?
>
> The short answer is "you can't".
>
> The longer answer is that you end up having to window it using
> segmentation;
Onl
On Thu, 26 Jul 2001, Hugh LaMaster wrote:
> - Since the mid-70's (that is 25 years now), logic/gates/real-estate
> are no longer (economically) scarce
> - Therefore, the key to the value/efficiency of any computer architecture
> is how well it uses memory
> - There are two key components to m
On Thu, 19 Jul 2001, Terry Lambert wrote:
> Julian Elischer wrote:
> > > hi, there!
> >
> > what is arcnet?
>
> Old PC networking standard, limited to 2Mbit/S.
I believe there is also 16 and 100 Mbit arcnet
hardware available ;)
At least, so I was told by one happy arcnet fan.
Rik
--
Virtual me
On Thu, 12 Jul 2001, Matt Dillon wrote:
> yield an immediate improvement in available mbuf space. For the receive
> side of things we can't really do anything with existing connections
> (because we've already advertised that the space is available to the
> remote end),
In emerg
On Mon, 9 Jul 2001, Mustafa N. Deeb wrote:
> how can I tell sendmail to deny this
>
> >>> MAIL From:<> SIZE=1926
> 250 <>... Sender ok
Please see http://www.rfc-ignorant.org/
Denying these headers will get you blacklisted.
Rik
--
Virtual memory is like a game you can't win;
However, without VM
On Tue, 26 Jun 2001, Wes Peters wrote:
> Rik van Riel wrote:
> > On Sun, 24 Jun 2001, Rahul Siddharthan wrote:
> > > Wes Peters said on Jun 23, 2001 at 23:28:42:
> > > > > Plenty of GNU stuff there, though it doesn't say so explicitly.
> > > > >
On Sun, 24 Jun 2001, Rahul Siddharthan wrote:
> Wes Peters said on Jun 23, 2001 at 23:28:42:
> > > Plenty of GNU stuff there, though it doesn't say so explicitly.
> > > Of course, they say it's all meant only for "legacy Unix" stuff.
> >
> > Can you substantiate your claim there is "plenty of GNU
On 21 Jun 2001, Dag-Erling Smorgrav wrote:
> "Andy" <[EMAIL PROTECTED]> writes:
> > http://linuxtoday.com/news_story.php3?ltsn=2001-06-20-018-20-NW-MS-SW
>
> Doesn't this mean software developed with Microsoft's SDK is viral?
> And doesn't *that* mean you're not allowed to develop it with
> Micros
On Wed, 20 Jun 2001, Terry Lambert wrote:
> Back to swapping socket structures...
>
> You could swap them if you wanted to give up some KVA
> space to be able to do it.
Which is a problem, especially for Linux. The problem
here is that there are x86 machines around with 64GB of
RAM. Linux has j
On Wed, 20 Jun 2001, Matt Dillon wrote:
> I don't think this represents the biggest problem you would face,
> though. It is far more likely that hung or slow connections
> (e.g. the originator goes away without disconnecting the socket
> or the originator is on a slow link) will
On Sat, 16 Jun 2001, Jonathan Fortin wrote:
> Linux is tuned out of the box, where the others are tuned for
> stability.
Not quite. Linux distributions tend to be extremely
conservative in the IDE options (DMA, interrupt unmasking,
write caching, etc. all disabled) while FreeBSD seems to
have wr
On Sat, 16 Jun 2001, Matt Dillon wrote:
> This is old. The guys running the tests blew it in so many ways
> that you might as well have just rolled some dice. There's a slashdot
> article on it too, and quite a few of the reader comments on these
> bozos are correct. I especial
On Fri, 15 Jun 2001, Terry Lambert wrote:
> [ ... Eliza program for FreeBSD ... ]
>
> Doing this is non-trivial. Many of the things they should
> have tuned can not be tuned except at compile time.
I think you just hit the nail on the head and
managed to identify the problem...
regards,
Rik
-
On Thu, 31 May 2001, Søren Schmidt wrote:
> If somebody sends me the 800 US$ the software costs, or better
> get me the software for free (we are a free OS right) I'll gladly
> run it through a variety of machines here...
If you think this is the problem, I'll happily chip in $50;
it would be i
On Thu, 31 May 2001, Noses wrote:
> Thank you for not telling it to one of my servers which is running
> around with about 10 concurrent connections biting its tail. I
> wouldn't like to hurt its feelings. And I've got the feeling that it
> will have to bear a bit more of that beating.
Inter
On Wed, 30 May 2001, Albert D. Cahalan wrote:
> > I would suggest a better test would be to open _at least_
> > 250,000 connections to a server running under both FreeBSD
> > and Linux. I was able to do this without breaking a sweat
> > on a correctly configured FreeBSD 4.3 system.
>
> How abou
On Wed, 30 May 2001, Terry Lambert wrote:
> The intent of the "test" is obviously intended to show
> certain facts which we all know to be self-evident under
> strange load conditions which are patently "unreal".
> I would suggest a better test would be to open _at least_
> 250,000 connections t
On Mon, 28 May 2001, Daniel C. Sobral wrote:
> Rik van Riel wrote:
> > On Fri, 25 May 2001, Terry Lambert wrote:
> >
> > > So add an option to sysinstall called:
> > >
> > > "Fast and at least as reliable as Linux"
> >
> > I
On Sat, 26 May 2001, Peter Wemm wrote:
> Which is more expensive? Maintaining an on-disk hashed (or b+tree)
> directory format for *everything* or maintaining a simple low-cost
> format on disk with in-memory hashing for fast lookups?
I bet that for modest directory sizes the cost of disk IO ou
On Fri, 25 May 2001, Terry Lambert wrote:
> So add an option to sysinstall called:
>
> "Fast and at least as reliable as Linux"
I doubt FreeBSD would need to enable write caching in order
to be as fast as Linux (which doesn't have write caching
enabled in any distribution I'm aware of).
On Wed, 23 May 2001, Shannon wrote:
> On Wed, May 23, 2001 at 10:54:40PM -0300, Rik van Riel wrote:
>
> > 1. I don't think I've ever seen a Linux distro which has write
> >caching enabled by default. Hell, DMA33 isn't even enabled
> >by default ;)
&g
On Wed, 23 May 2001, Andresen,Jason R. wrote:
> On Wed, 23 May 2001, Kris Kennaway wrote:
> > That's all well and good, but I thought the aim here was to compare
> > Linux and FreeBSD performance on as level playing field as possible?
> > You're not measuring FS performance, you're measuring FS p
On Wed, 18 Apr 2001, Dennis wrote:
> >You think Intel isn't going to market dual/quad ia64 machines?
>
> Yes, but who'll need them?
If nobody needed them, what would be the point in SELLING
them ?
I know you don't trust our technical instinct, but you might
at least consider the business insti
Hi,
better back out SMPng real fast, otherwise you'll get into a
flamewar with Dennis again ;)
Rik
-- Forwarded message --
Date: Wed, 18 Apr 2001 11:08:22 -0400
From: Dennis <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: SMP in 2.4
Does 2.4 have something similar to spl leve
On Thu, 12 Apr 2001, Matt Dillon wrote:
> Again, keep in mind that the namei cache is strictly throw-away,
This seems to be the main difference between Linux and FreeBSD.
In Linux, open files directly refer to an entry in the dentry
(and inode) cache, so we really need to have dynamically g
On Tue, 10 Apr 2001, Matt Dillon wrote:
>It's randomness that will kill performance. You know the old saying
>about caches: They only work if you get cache hits, otherwise
>they only slow things down.
I wonder ... how does FreeBSD handle negative directory entries?
That is, /bin/s
On Tue, 10 Apr 2001, Matt Dillon wrote:
> :I'm curious about the other things though ... FreeBSD still seems
> :to have the early 90's abstraction layer from Mach and the vnode
> :cache doesn't seem to grow and shrink dynamically (which can be a
> :big win for systems with lots of metadata activi
On Tue, 10 Apr 2001, Matt Dillon wrote:
> :I heard NetBSD has implemented a FreeBSD like VM, it also implemented
> :a VM balance in recent verion of NetBSD. some parameters like TEXT,
> :DATA and anonymous memory space can be tuned. is there anyone doing
> :such work on FreeBSD or has FreeBSD alr
On Tue, 3 Apr 2001, Dennis wrote:
> This "consumer" attitude that you are doing a company a favor by
> buying something from them is completely misguided. Most companies are
> not some ISP or consultant struggling to pay its bills. WE are doing
> you a favor by making our technology available to
On Thu, 22 Mar 2001, thinker wrote:
> On Wed, Mar 21, 2001 at 04:14:32PM -0300, Rik van Riel wrote:
> > The (maybe too lightweight) structure I have in my patch
> > looks like this:
> >
> > struct pte_chain {
> > struct pte_chain * next;
> > pte_t
On Wed, 21 Mar 2001, Matt Dillon wrote:
> We've looked at those structures quite a bit. DG and I talked about
> it a year or two ago but we came to the conclusion that the extra
> linkages in our pv_entry gave us significant performance benefits
> during rundowns. Since then Tor
On Wed, 21 Mar 2001, Peter Wemm wrote:
> Also, 4MB = 1024 pages, at 28 bytes per mapping == 28k per process.
28 bytes/mapping is a LOT. I've implemented an (admittedly
not completely architecture-independent) reverse mapping
patch for Linux with an overhead of 8 bytes/pte...
I wonder how hard/
On Tue, 13 Mar 2001, Charles Randall wrote:
> From: David O'Brien [mailto:[EMAIL PROTECTED]]
> >2. The base, system C compiler is known to produce bad code with -O2.
> >We have been proclaiming this since as long as I have been with the
> >Project.
>
> Is this an issue with FreeBSD's gcc
On Sun, 4 Mar 2001, Jordan DeLong wrote:
> On Sun, Mar 04, 2001 at 11:08:51AM +, Jordan DeLong wrote:
> > clone() wont count against the per uid process limit, right?
> actually I just realized it'd be incredibly stupid for clone not to
> count against the per uid process limit
It does the
On Mon, 26 Feb 2001, Peter Seebach wrote:
> In message <[EMAIL PROTECTED]>,
> >And maybe, just maybe, they'll succeed in getting their
> >idea of non-overcommit working with a patch which doesn't
> >change dozens of places in the kernel and doesn't add
> >any measurable overhead.
>
> If it adds ov
On Tue, 27 Feb 2001, Daniel C. Sobral wrote:
> Matt Dillon wrote:
> > :Matt Dillon wrote:
> > :>
> > :..
> > :> the system runs out of memory, even *with* overcommit protection.
> > :> In fact, all sorts of side effects occur even when the system
> > :...
> > :
> > :That's an assumption.
>
On Sun, 25 Feb 2001, Matt Dillon wrote:
> The problem is a whole lot more complex then you think. Dealing with
> overcommit is not simply counting mapped pages, there are all sorts
> of issues involved. But the biggest gotcha is that putting in
> overcommit protection will not a
On Sat, 24 Feb 2001, Peter Seebach wrote:
> In message <9820.983050024@critter>, Poul-Henning Kamp writes:
> >I think there is a language thing you don't understand here.
>
> No, I just disagree. It is useful for the OS to provide a hook for
> memory which is *known to work* - and that is the env
On Tue, 6 Feb 2001, Andre Oppermann wrote:
> Rik van Riel wrote:
> > On Tue, 6 Feb 2001, Andre Oppermann wrote:
> >
> > > But please answer me one question: Is the link() call atomically
> > > in FFS/UFS w or w/o softupdates? Meaning when the call returns
&
On Tue, 6 Feb 2001, Andre Oppermann wrote:
> But please answer me one question: Is the link() call atomically
> in FFS/UFS w or w/o softupdates? Meaning when the call returns
> the meta- data is written to stable storage like with fsync()?
Since when does `atomic' equal `synchronous' ?
regards,
On Tue, 6 Feb 2001, Andre Oppermann wrote:
> Rik van Riel wrote:
> > On Tue, 6 Feb 2001, Matt Dillon wrote:
> >
> > Reiserfs and ext3 have write-ahead logs and, AFAIK, fsync()
> > will not return until there is a commit point in the log.
>
> Also FFS/UFS wi
On Tue, 6 Feb 2001, Andre Oppermann wrote:
> Qmail depends on ordered-metadata updates (Terry! :-). That
> means if you issue a link() to the new place and a unlink() in
> the old place it should guarantee that the link() happens
> *BEFORE* the unlink().
> > As it is, I can only recommend people
On Tue, 6 Feb 2001, Andre Oppermann wrote:
> Date: Tue, 06 Feb 2001 20:32:07 +0100
> From: Andre Oppermann <[EMAIL PROTECTED]>
> NAME
> link - make a hard file link
> DESCRIPTION
> The link() function call atomically creates the specified directory
> entry
>
On Tue, 6 Feb 2001, Matt Dillon wrote:
> :Reiserfs and ext3 have write-ahead logs and, AFAIK, fsync()
> :will not return until there is a commit point in the log.
> :
> :This means that fsync() will guarantee that the transactions
> :won't be unwound (unless I've overlooked some weird special
> :
On Tue, 6 Feb 2001, Matt Dillon wrote:
> QMail's FAQ is totally incorrect. No major filesystem -- be it
> FFS, EX2FS, Reiser, FFS+Softupdates, guarentees that when you
> write() and close() a file that the file will then survive a disk
> crash. All these filesystems guarentee is
On Tue, 6 Feb 2001, Mike Silbersack wrote:
> On Tue, 6 Feb 2001, Rik van Riel wrote:
>
> > The system call used to guarantee this is fsync (and friends?);
> > if qmail doesn't use it but makes assumptions that aren't true
> > on any decent OS out there ...
>
On Tue, 6 Feb 2001, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>,
>Charles Randall writes:
> >The qmail FAQ specifically recommends against soft updates for the mail
> >queue.
> >
> >http://cr.yp.to/qmail/faq/reliability.html#filesystems
> >
> >Is this incorrect?
>
> It seems to ind
On Mon, 5 Feb 2001, Matt Dillon wrote:
> :file: table is full
> :looutput: mbuf allocation failed
> :nfs server 172.16.0.101:/bravenet1/home: is alive again
> This sheds a considerable amount of light on the problems...
> methinks you may have a low 'maxusers' setting in the kernel
>
On Thu, 1 Feb 2001, Warner Losh wrote:
> We've had horrible luck with the realtek 8139 with a few of our
> 10MBps hubs.
I've seen the same problem here. My 8139 card is currently
going to the switch at 100Mbit/s, which runs stable with
Linux 2.4.0, even on my BP6 ;)
However, because of a lack o
On Sun, 7 Jan 2001, Jeremiah Gowdy wrote:
> You're saying the most common definition of "free" isn't no cost ?
I'm a free man, not a commercial sample!
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.co
On Wed, 27 Dec 2000, Jeremiah Gowdy wrote:
> If you slant your judgement so far against the other products,
> it makes you sound like you don't know what you're talking about
> (no offense). You need to point out the pros and cons of ALL
> three systems. Not just the pros of FreeBSD and the con
On Sat, 23 Dec 2000, Jeremiah Gowdy wrote:
> FreeBSD advocacy is prefectly alright.
>
> And there's nothing wrong with calling them Linux weenies in
> FreeBSD circles :) I usually don't even say it that nicely when
> I'm referring to the more rabid Linux "weenies": "Linux is
> better than anyt
On Fri, 22 Dec 2000, Julian Stacey [EMAIL PROTECTED] wrote:
> Matt Dillon wrote:
> > :Reverse engineering is a myth. The result is so inferior to high-level
> > :language source code as to not be a concern, plus its illegal so it cant be
> > :marketed.
> > Reverse engineering is very legal,
On Tue, 19 Dec 2000, Matt Dillon wrote:
> Yes, it's a pretty sad state of affairs. What annoys me the most is
> that companies actually believe they are protecting something when
> they don't make their device driver source or hardware documentation
> available. It has been well
On Mon, 18 Dec 2000, Murray Stokely wrote:
> I want to create a comprehensive body of knowledge that can
> then be used to make fliers to hand out to Linux weenies at
^
> trade shows, published on bsdi.com and/or freebsd.org, etc..
Haha
On Thu, 16 Nov 2000, Terry Lambert wrote:
> > Ummm, how about a situation where you have a steadily
> > increasing work load (more customers?) and want to have
> > decent statistics of your servers to determine exactly
> > what parts to upgrade and/or if you need to put extra
> > machines into se
On Thu, 16 Nov 2000, Terry Lambert wrote:
> > > Modern bloat-ware really pisses me off; I built the bind
> > > library the other day: the frigging thing was 4M, unstripped.
> >
> > How does this affect the (non?-)usefullness of the
> > %iowait statistic?
>
> When you are waiting for I/O in a we
On Wed, 15 Nov 2000, Terry Lambert wrote:
> > > > Thank you! This gets the me disk %busy, which is one of the things I
> > > > was looking for. Now, can anyone tell me how to tell what percentage of
> > > > processor time is being spent waiting for disk I/O to complete?
> > >
> > > Uh, none?
>
On Fri, 10 Nov 2000, Terry Lambert wrote:
> > Thank you! This gets the me disk %busy, which is one of the things I
> > was looking for. Now, can anyone tell me how to tell what percentage of
> > processor time is being spent waiting for disk I/O to complete?
>
> Uh, none?
>
> If there is disk
On Thu, 2 Nov 2000, Don Muller wrote:
> Well, the company did not explain how, or why it happened. The
> programmer I work with suggested BSD.Of course I wanted security!
> Well, they gave me some explanation that the server was hacked at the
> xfs port. But later I was told that the ftp port on
On Sun, 15 Oct 2000, Stephen Hocking wrote:
> The Linux box appears toknow about the users, it just cant get
> the passwords right - something tickles my mind about DES vs
> MD5, is this the case, and how do I convert my MD5 passwords if
> needed?
Not needed. Configure both machines to use the s
On Fri, 29 Sep 2000, Doug White wrote:
> On Thu, 28 Sep 2000, Marc Tardif wrote:
>
> > What is the quickest way of writing large amounts of data to disk?
>
> Sequentially. Disks run an order of magnitude faster if they
> have sequential data. Don't get too fancy with the ordering
> since the dis
84 matches
Mail list logo
