mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vladislav Bolkhovitin <vst@vlnb.net>
To: Christoph Hellwig <hch@infradead.org>
Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>,
	target-devel <target-devel@vger.kernel.org>,
	linux-scsi <linux-scsi@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Mike Christie <michaelc@cs.wisc.edu>,
	Hannes Reinecke <hare@suse.de>,
	Roland Dreier <roland@purestorage.com>,
	Andy Grover <agrover@redhat.com>, Christoph Hellwig <hch@lst.de>,
	stable@vger.kernel.org
Subject: Re: [PATCH 1/6] target/file: Re-enable optional fd_buffered_io=1 operation
Date: Tue, 02 Oct 2012 15:02:17 -0400	[thread overview]
Message-ID: <506B3A39.9010408@vlnb.net> (raw)
In-Reply-To: <20121001084605.GA23497@infradead.org>

Christoph Hellwig, on 10/01/2012 04:46 AM wrote:
> On Sun, Sep 30, 2012 at 05:58:11AM +0000, Nicholas A. Bellinger wrote:
>> From: Nicholas Bellinger<nab@linux-iscsi.org>
>>
>> This patch re-adds the ability to optionally run in buffered FILEIO mode
>> (eg: w/o O_DSYNC) for device backends in order to once again use the
>> Linux buffered cache as a write-back storage mechanism.
>>
>> This difference with this patch is that fd_create_virtdevice() now
>> forces the explicit setting of emulate_write_cache=1 when buffered FILEIO
>> operation has been enabled.
>
> What this lacks is a clear reason why you would enable this inherently
> unsafe mode.  While there is some clear precedence to allow people doing
> stupid thing I'd least like a rationale for it, and it being documented
> as unsafe.

Nowadays nearly all serious applications are transactional, and know how to flush 
storage cache between transactions. That means that write back caching is 
absolutely safe for them. No data can't be lost in any circumstances.

Welcome to the 21 century, Christoph!

Vlad

  reply	other threads:[~2012-10-02 19:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-30  5:58 [PATCH 0/6] target: Reenable buffered FILEIO + add iscsi-target MXDSL logic Nicholas A. Bellinger
2012-09-30  5:58 ` [PATCH 1/6] target/file: Re-enable optional fd_buffered_io=1 operation Nicholas A. Bellinger
2012-10-01  8:46   ` Christoph Hellwig
2012-10-02 19:02     ` Vladislav Bolkhovitin [this message]
2012-10-02 20:16     ` Nicholas A. Bellinger
2012-10-03 11:47       ` Christoph Hellwig
2012-10-04  0:02         ` Nicholas A. Bellinger
2012-09-30  5:58 ` [PATCH 2/6] iscsi-target: Add base MaxXmitDataSegmentLength code Nicholas A. Bellinger
2012-09-30  5:58 ` [PATCH 3/6] iscsi-target: Enable MaxXmitDataSegmentLength operation in login path Nicholas A. Bellinger
2012-09-30  5:58 ` [PATCH 4/6] iscsi-target: Convert incoming PDU payload checks to MaxXmitDataSegmentLength Nicholas A. Bellinger
2012-09-30  5:58 ` [PATCH 5/6] iscsi-target: Add MaxXmitDataSegmentLength connection recovery check Nicholas A. Bellinger
2012-09-30  5:58 ` [PATCH 6/6] iscsi-target: Change iscsi_target_seq_pdu_list.c to honor MaxXmitDataSegmentLength Nicholas A. Bellinger

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=506B3A39.9010408@vlnb.net \
    --to=vst@vlnb.net \
    --cc=agrover@redhat.com \
    --cc=hare@suse.de \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michaelc@cs.wisc.edu \
    --cc=nab@linux-iscsi.org \
    --cc=roland@purestorage.com \
    --cc=stable@vger.kernel.org \
    --cc=target-devel@vger.kernel.org \
    /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®