mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ray Lee <ray-lk@madrabbit.org>
To: Hua Zhong <hzhong@gmail.com>
Cc: Theodore Tso <tytso@mit.edu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jens Axboe <jens.axboe@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/8][RFC] IO latency/throughput fixes
Date: Mon, 6 Apr 2009 15:48:00 -0700	[thread overview]
Message-ID: <2c0942db0904061548x2d34eff7g9b5332826509da53@mail.gmail.com> (raw)
In-Reply-To: <003401c9b706$9c4c1b50$d4e451f0$@com>

On Mon, Apr 6, 2009 at 3:25 PM, Hua Zhong <hzhong@gmail.com> wrote:
> You are implying that if someone upgrades their kernel, then he must
> 1) upgrade it continuously and 2) without any scrutiny. Both are untrue.

Great, then they'll notice the default ext3 data mode changed, and
adjust their scripts accordingly. Problem solved.

> There are certain things people expect from the kernel, such as
> no ABI changes. To me ext3 default option falls into this category.

As the past several hundred messages on this topic has just shown,
while people may expected metadata vs data ordering to be a guarantee,
apparently it never was unless you specifically mounted your ext3
filesystem with data=ordered. The default was only that, a default,
and one that can still be specified explicitly.

> And even if they are nuts, you can't prove they don't exist, especially
> given how many software already depends on the ordered mode.

There are an unbounded number of possible incorrect setups in the
world. Should we live in fear of their existence without any proof?

> You also conveniently forgot to quote my question about security. Both
> are valid questions, not something I just totally made up.

Security on an embedded device starts with controlling physical
access. If they have access to the storage media all bets are off,
whether it's data=ordered or not. (Access to the storage media is
really what we're talking about here -- medical data, for example,
hitting the platter before the metadata updates that then make that
data unaccessible to other userspace processes.)

Because *if* they have access to the media, they can replace any
running code on that box, and your security is worthless.

So no, I don't see how that's a valid argument.

>> If they're willing to upgrade their kernel blindly, then they
>> shouldn't be doing embedded development.
>
> Linus once said that if you don't understand "not breaking user space" then
> you should not be doing kernel development. Or something to that extent.

Luckily, I do understand, and have argued on user-space's behalf for
years now. But your argument was hypothetical embedded developers who
upgrade their kernels without seeing what defaults changed, and then
getting burned by the different semantics. I can't muster up enough
give-a-damn to care about a minute percentage of the population (us
embedded developers) who aren't doing their job of reading
kernelnewbies to see what changed.

I accept Linus' argument that the change in crash behavior for random
folk is going to be very different, and that perhaps that alone should
drive keeping the default as it is today, but now we're talking about
the desktop space.

  reply	other threads:[~2009-04-06 22:48 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-06 12:48 Jens Axboe
2009-04-06 12:48 ` [PATCH 1/8] block: change the request allocation/congestion logic to be sync/async based Jens Axboe
2009-04-06 12:48 ` [PATCH 2/8] Add WRITE_SYNC_PLUG and SWRITE_SYNC_PLUG Jens Axboe
2009-04-06 12:48 ` [PATCH 3/8] block: fsync_buffers_list() should use SWRITE_SYNC_PLUG Jens Axboe
2009-04-06 12:48 ` [PATCH 4/8] jbd: use WRITE_SYNC_PLUG instead of WRITE_SYNC Jens Axboe
2009-04-06 12:48 ` [PATCH 5/8] jbd2: " Jens Axboe
2009-04-06 12:48 ` [PATCH 6/8] block: enabling plugging on SSD devices that don't do queuing Jens Axboe
2009-04-06 12:48 ` [PATCH 7/8] block: Add flag for telling the IO schedulers NOT to anticipate more IO Jens Axboe
2009-04-06 12:48 ` [PATCH 8/8] block: switch sync_dirty_buffer() over to WRITE_SYNC Jens Axboe
2009-04-06 13:04 ` [PATCH 0/8][RFC] IO latency/throughput fixes Jens Axboe
2009-04-06 13:13   ` Jens Axboe
2009-04-06 15:37   ` Linus Torvalds
2009-04-06 16:57     ` Jens Axboe
2009-04-07  3:28     ` Chris Mason
2009-04-06 15:04 ` Linus Torvalds
2009-04-06 15:10   ` Jens Axboe
2009-04-06 15:45     ` Linus Torvalds
2009-04-06 17:01       ` Jens Axboe
2009-04-06 18:31       ` Theodore Tso
2009-04-06 19:57         ` Linus Torvalds
2009-04-06 20:10           ` Linus Torvalds
2009-04-06 21:26             ` Theodore Tso
2009-04-06 20:12           ` Hua Zhong
2009-04-06 20:20             ` Linus Torvalds
2009-04-06 21:19             ` Theodore Tso
2009-04-06 21:35               ` Hua Zhong
2009-04-06 22:04                 ` Ray Lee
2009-04-06 22:17                   ` Linus Torvalds
2009-04-06 23:10                     ` Linus Torvalds
2009-04-07  7:51                       ` Geert Uytterhoeven
2009-04-07 10:36                         ` Ingo Molnar
2009-04-07 14:10                           ` Diego Calleja
2009-04-08 12:04                             ` Ingo Molnar
2009-04-08 12:56                           ` Denys Vlasenko
2009-04-08 13:27                             ` Ingo Molnar
2009-04-07 13:35                       ` Mark Lord
2009-04-07 14:33                         ` Linus Torvalds
2009-04-07 19:24                           ` Mark Lord
2009-04-07 19:45                             ` Jeff Garzik
2009-04-07 20:53                           ` Mike Galbraith
2009-04-09  2:40                       ` Eric Sandeen
2009-04-09 14:01                         ` Ric Wheeler
2009-04-06 22:25                   ` Hua Zhong
2009-04-06 22:48                     ` Ray Lee [this message]
2009-04-06 22:52                       ` Hua Zhong
2009-04-06 23:19                       ` Alan Cox
2009-04-07  3:52               ` Chris Mason
2009-04-07  4:13                 ` Trenton D. Adams
2009-04-07  4:27                   ` Linus Torvalds
2009-04-07  4:48                     ` Trenton D. Adams
2009-04-07  5:02                       ` Linus Torvalds
2009-04-07  5:23                         ` Hua Zhong
2009-04-07  6:27                         ` Trenton D. Adams

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=2c0942db0904061548x2d34eff7g9b5332826509da53@mail.gmail.com \
    --to=ray-lk@madrabbit.org \
    --cc=hzhong@gmail.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    /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

all inboxes | Powered by JetHome®