ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: ksummit <ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Project Banbury
Date: Sun, 16 Sep 2018 09:25:00 -0700	[thread overview]
Message-ID: <CA+55aFyUd4bqPNtV7W7=aMXtMfMw2c+18akRkL_XYAX=oUPRtg@mail.gmail.com> (raw)
In-Reply-To: <2499181.JFuLfGgBK5@avalon>

On Sun, Sep 16, 2018 at 9:03 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> >
> > http://www.wil.cx/~willy/banbury.html
>
> Having lost a server due to a DDoS attach that rendered the link between CPU
> and storage unusable for a too long time, I think this would be an amazing
> improvement.

I agree on the "amazing", but in a more literal sense. I don't think
it's all that realistic. Pausing IO will basically hang the machine,
and you'll run out of memory in not too long too.

It's probably doable with a mount option and filesystem help (aka
"intr" for NFS). But people should be aware that one reason "intr"
worked as well as it did for NFS was that it

 (a) broke POSIX rules

 (b) NFS traditionally did almost synchronous writes

 (c) the metadata is/was on the disconnected side

and even then, you really really didn't want NFS "intr" to be on a
core filesystem.

With hotplug devices, you have some "interesting" issues in addition,
namely making sure you really connect it back to the right disk, and
don't re-use *anything* in case it turns out it's not the same one.
Even for the "simple" USB case, you'll have serious issues with the
serial numbers not being reliable (maybe things are better now, but it
used to be that the supposedly "unique" USB serial number wasn't
unique at all).

So I think it would be a good addition, but people should realize that
the current behavior is there for some pretty fundamental reasons.

               Linus

  reply	other threads:[~2018-09-16 16:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-14 17:28 Matthew Wilcox
2018-09-16 10:53 ` Hannes Reinecke
2018-09-16 12:45   ` Matthew Wilcox
2018-09-18  8:17     ` Hannes Reinecke
2018-09-16 16:03 ` Laurent Pinchart
2018-09-16 16:25   ` Linus Torvalds [this message]
2018-09-16 16:37 ` James Bottomley
2018-09-16 19:25   ` Theodore Y. Ts'o
2018-09-16 23:58 ` David Howells

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='CA+55aFyUd4bqPNtV7W7=aMXtMfMw2c+18akRkL_XYAX=oUPRtg@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=laurent.pinchart@ideasonboard.com \
    /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