public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: "Salyzyn, Mark" <mark_salyzyn@adaptec.com>
Cc: SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: RE: [linux-iscsi-devel] [question] deferred sense
Date: Thu, 06 Jan 2005 10:50:27 -0500	[thread overview]
Message-ID: <1105026628.4319.32.camel@mulgrave> (raw)
In-Reply-To: <60807403EABEB443939A5A7AA8A7458B9B96C3@otce2k01.adaptec.com>

On Thu, 2005-01-06 at 09:57 -0500, Salyzyn, Mark wrote:
> The key to higher performance is a cluster solution that permits cache
> on, and in doing so, the issues of deferred failure is similar. I am not
> talking pie in the sky here; there are proprietary solutions (from low
> end all the way up to the `world scale cache' of the Yotta-Yotta's of
> the world)

HA is about safety first and then performance.  Something with a local
writeback cache is always HA unsafe and thus it won't be supported by
the major HA vendors.

> The point is deferred failure is not the only user of these changes to
> the file-system layer. In the low end, this kind of technology is being
> added to Windoze and has been part of Netware (including complete system
> memory synchronization between failover machines) for years; there are
> customers of redundant solutions that require this.
> 
> In the Public Domain, simplicity usually drives adoption (just measure
> the pain Sistina had asking for a new atomic SCSI command). I am not
> sure the General Purpose customer wants to 'pay' for unused complexity
> and the accompanying doubt of stability ...

I'll agree but only if you can't achieve the desired end by simple
means.  In this case, you can, you set the cache to writethrough and the
problem goes away.

James



  reply	other threads:[~2005-01-06 15:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-06 14:57 [linux-iscsi-devel] [question] deferred sense Salyzyn, Mark
2005-01-06 15:50 ` James Bottomley [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-01-06 14:23 Salyzyn, Mark
2005-01-06 14:38 ` James Bottomley
2005-01-05 17:47 Salyzyn, Mark
2005-01-05 21:51 ` James Bottomley
2005-01-05 22:58   ` Matthew Wilcox
2005-01-06 23:09   ` Bryan Henderson
     [not found] <41DB21D7.5080904@us.ibm.com>
     [not found] ` <20050104234700.GA18343@visi.com>
     [not found]   ` <20050105092144.GB26793@lst.de>
     [not found]     ` <20050105152112.GA8472@visi.com>
2005-01-05 15:23       ` Christoph Hellwig
2005-01-05 16:44         ` James Bottomley
2005-01-06 16:37           ` Tom Coughlan
2005-01-07  0:06             ` Douglas Gilbert
2005-01-11 11:44               ` Douglas Gilbert

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=1105026628.4319.32.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mark_salyzyn@adaptec.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