From: Bart Van Assche <bart.vanassche@sandisk.com>
To: "doug@easyco.com" <doug@easyco.com>
Cc: Christoph Hellwig <hch@infradead.org>,
device-mapper development <dm-devel@redhat.com>
Subject: Re: API for multi-segment atomic IO
Date: Thu, 9 Jul 2015 10:24:22 -0700 [thread overview]
Message-ID: <559EAE46.8000706@sandisk.com> (raw)
In-Reply-To: <CAFx4rwRBh4ix1d84rzo=_0MiLABNObA54cbBNZ5RKTnWpT78mg@mail.gmail.com>
On 07/09/2015 10:09 AM, Doug Dumitru wrote:
> The problem with this is that the SCSI commands do not go far enough to
> actually address the needs of applications that need atomic updates. An
> application would "like" to be able to update a large arbitrary set, of
> sectors on a device with atomic semantics. The SCSI commands require the
> set to be contiguous. Application design starts to get interesting when
> the contiguous restriction goes away.
>
> My initial thoughts are to tag multiple IO requests with an ID and
> combined length field. This would be compatible with the SCSI spec if
> the request was contiguous, but nonsensical if the request were
> multi-segment. On the other hand, just hitting the SCSI spec is
> probably as simple as adding an "atomic" bit to the current structure so
> that IO pieces are not cut up. But then, you don't address the
> multi-segment functionality that is possible. Regardless, there will be
> issues as pieces of the current stack don't lend themselves well to
> propagating atomic operations up and down the stack. Just how do you
> split an atomic write across scsi devices in a raid set anyway?
>
> What I am most interested in is keeping the stack working with at least
> 1:1 mapping layers, and with 1:many layers below the layer that
> implements the atomic functionality. Think of a dm-atomic.ko device
> that uses a log internally to implement multi-segment atomic writes. It
> can talk safely to raid below it, but lvm should be able to sit above it
> and still have a file system that expects atomic functionality to work.
> Now getting a SAN connection to work like this would involve a new
> transport as iSCSI doesn't really have the semantics for this, but maybe
> there are some extra "transaction ID" bits that could be put into play
> (it has been a long time since I dug into the depths of the SCSI layers).
Hello Doug,
The original proposal, from which the SBC-4 ATOMIC WRITE specification
has been derived, had support for scattered writes and gathered reads.
The title of that document is "SBC-4 SPC-5 Atomic writes and reads"
(http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-043r4.pdf).
Bart.
next prev parent reply other threads:[~2015-07-09 17:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-08 3:33 API for multi-segment atomic IO Doug Dumitru
2015-07-08 15:38 ` Bart Van Assche
2015-07-08 16:21 ` Doug Dumitru
2015-07-08 19:38 ` Christoph Hellwig
2015-07-09 15:41 ` Doug Dumitru
2015-07-09 16:34 ` Bart Van Assche
2015-07-09 17:08 ` Doug Dumitru
2015-07-09 17:24 ` Bart Van Assche [this message]
2015-07-09 20:39 ` Doug Dumitru
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=559EAE46.8000706@sandisk.com \
--to=bart.vanassche@sandisk.com \
--cc=dm-devel@redhat.com \
--cc=doug@easyco.com \
--cc=hch@infradead.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 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.