From: Joel Becker <Joel.Becker@oracle.com> To: Linus Torvalds <torvalds@osdl.org> Cc: Trond Myklebust <trond.myklebust@fys.uio.no>, Ulrich Drepper <drepper@redhat.com>, Linux Kernel <linux-kernel@vger.kernel.org> Subject: Re: statfs() / statvfs() syscall ballsup... Date: Fri, 10 Oct 2003 10:33:44 -0700 [thread overview] Message-ID: <20031010173344.GC29301@ca-server1.us.oracle.com> (raw) In-Reply-To: <Pine.LNX.4.44.0310100939300.20420-100000@home.osdl.org> On Fri, Oct 10, 2003 at 09:50:02AM -0700, Linus Torvalds wrote: > The fact is, the high end is getting smaller and smaller. If Oracle wants > to go after that high-end-only market, then be my guest. No, the high-end for hardware is getting smaller. The need for high-end jobs is just fine. But as you point out, the high-end jobs are being done by low-end hardware. And here is Oracle, promoting a bank of cheap-ass 2-way boxen to do the job. > Have you guys learnt _nothing_ from the past? The reason MicroSoft and > Linux are kicking all the other vendors butts is that _small_ is > beautiful. Especially when small is "powerful enough". Again, we need this sort of stuff precisely because we'd rather use 2 $5k Linux/Intel servers than 1 $40k Sun server (and the Linux box outruns the Sun, quite comfortably). That's the "powerful enough", right there. > And believing that the load will keep up with "big iron hardware" is just > not _true_. It's never been true. "Small iron" not only keeps up, but > overtakes it - to the point where you have to start doing new things just > to be able to take advantage of it. Linus, I've said it twice above. This has been our entire direction for the past couple years, and we've been loud about it. Please, knock us for what we do wrong, but recognize what we are actually doing wrong, not what you think we are doing. > Ok. Let's just hope all the crackers and virus writers believe you when > you say "you shouldn't do that". Well, if a cracker and virus writer can get enough priviledge to write(), cached or O_DIRECT, they can corrupt you without worrying about this specific gotcha. That doesn't mean you don't fix it, but it also doesn't mean you throw up your hands and claim you can't do it. > BIG FRIGGING HINT: a _real_ OS doesn't allow data corruption even for > cases where "you shouldn't do that". It shouldn't allow reading of data > that you haven't written. And "you shouldn't do that" is _not_ an excuse > for having bad interfaces that cause problems. I know that, I agree with it, and I said as much a few emails past. Linux should refuse to corrupt your data. But you've taken the tack "It is unsafe today, so we should abandon it altogether, never mind fixing it.", which doesn't logically follow. Joel -- "Behind every successful man there's a lot of unsuccessful years." - Bob Brown Joel Becker Senior Member of Technical Staff Oracle Corporation E-mail: joel.becker@oracle.com Phone: (650) 506-8127 -- "When choosing between two evils, I always like to try the one I've never tried before." - Mae West Joel Becker Senior Member of Technical Staff Oracle Corporation E-mail: joel.becker@oracle.com Phone: (650) 506-8127
next prev parent reply other threads:[~2003-10-10 17:34 UTC|newest] Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-10-09 22:16 Trond Myklebust 2003-10-09 22:26 ` Linus Torvalds 2003-10-09 23:19 ` Ulrich Drepper 2003-10-10 0:22 ` viro 2003-10-10 4:49 ` Jamie Lokier 2003-10-10 5:26 ` Trond Myklebust 2003-10-10 12:37 ` Jamie Lokier 2003-10-10 13:46 ` Trond Myklebust 2003-10-10 14:35 ` Jamie Lokier 2003-10-10 15:32 ` Misc NFSv4 (was Re: statfs() / statvfs() syscall ballsup...) Trond Myklebust 2003-10-10 15:53 ` Jamie Lokier 2003-10-10 16:07 ` Trond Myklebust 2003-10-10 15:55 ` Michael Shuey 2003-10-10 16:20 ` Trond Myklebust 2003-10-10 16:45 ` J. Bruce Fields 2003-10-10 14:39 ` statfs() / statvfs() syscall ballsup Jamie Lokier 2003-10-09 23:31 ` Trond Myklebust 2003-10-10 12:27 ` Joel Becker 2003-10-10 14:59 ` Linus Torvalds 2003-10-10 15:27 ` Joel Becker 2003-10-10 16:00 ` Linus Torvalds 2003-10-10 16:26 ` Joel Becker 2003-10-10 16:50 ` Linus Torvalds 2003-10-10 17:33 ` Joel Becker [this message] 2003-10-10 17:51 ` Linus Torvalds 2003-10-10 18:13 ` Joel Becker 2003-10-10 16:27 ` Valdis.Kletnieks 2003-10-10 16:33 ` Chris Friesen 2003-10-10 17:04 ` Linus Torvalds 2003-10-10 17:07 ` Linus Torvalds 2003-10-10 17:21 ` Joel Becker 2003-10-10 16:01 ` Jamie Lokier 2003-10-10 16:33 ` Joel Becker 2003-10-10 16:58 ` Chris Friesen 2003-10-10 17:05 ` Trond Myklebust 2003-10-10 17:20 ` Joel Becker 2003-10-10 17:33 ` Chris Friesen 2003-10-10 17:40 ` Linus Torvalds 2003-10-10 17:54 ` Trond Myklebust 2003-10-10 18:05 ` Linus Torvalds 2003-10-10 20:40 ` Trond Myklebust 2003-10-10 21:09 ` Linus Torvalds 2003-10-10 22:17 ` Trond Myklebust 2003-10-11 2:53 ` Andrew Morton 2003-10-11 3:47 ` Trond Myklebust 2003-10-10 18:05 ` Joel Becker 2003-10-10 18:31 ` Andrea Arcangeli 2003-10-10 20:33 ` Helge Hafting 2003-10-10 20:07 ` Jamie Lokier 2003-10-12 15:31 ` Greg Stark 2003-10-12 16:13 ` Linus Torvalds 2003-10-12 22:09 ` Greg Stark 2003-10-13 8:45 ` Helge Hafting 2003-10-15 13:25 ` Ingo Oeser 2003-10-15 15:03 ` Greg Stark 2003-10-15 18:37 ` Helge Hafting 2003-10-16 10:29 ` Ingo Oeser 2003-10-16 14:02 ` Greg Stark 2003-10-21 11:47 ` Ingo Oeser 2003-10-10 18:20 ` Andrea Arcangeli 2003-10-10 18:36 ` Linus Torvalds 2003-10-10 19:03 ` Andrea Arcangeli 2003-10-09 23:16 ` Andreas Dilger 2003-10-09 23:24 ` Linus Torvalds
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=20031010173344.GC29301@ca-server1.us.oracle.com \ --to=joel.becker@oracle.com \ --cc=drepper@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=torvalds@osdl.org \ --cc=trond.myklebust@fys.uio.no \ --subject='Re: statfs() / statvfs() syscall ballsup...' \ /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
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.