From: Vladislav Bolkhovitin <vst@vlnb.net>
To: Tejun Heo <tj@kernel.org>
Cc: jaxboe@fusionio.com, linux-fsdevel@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org,
hch@lst.de, James.Bottomley@suse.de, tytso@mit.edu,
chris.mason@oracle.com, swhiteho@redhat.com,
konishi.ryusuke@lab.ntt.co.jp, dm-devel@redhat.com, jack@suse.cz,
rwheeler@redhat.com, hare@suse.de
Subject: Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush
Date: Fri, 13 Aug 2010 16:55:33 +0400 [thread overview]
Message-ID: <4C6540C5.8070108@vlnb.net> (raw)
In-Reply-To: <1281616891-5691-1-git-send-email-tj@kernel.org>
Tejun Heo, on 08/12/2010 04:41 PM wrote:
> Each filesystem needs to be updated to enforce request
> ordering themselves and then to use REQ_FLUSH/FUA mechanism.
I generally agree with the patchset, but I believe this particular move
is a really bad move.
I'm not mentioning the obvious that a common functionality (enforcing
requests ordering in this case) should be handled by a common library,
but not internally by a zillion file systems Linux has.
The worst in this move is that it would hide all the requests ordering
semantic inside file systems in, most likely, a very much unclear way.
That would lead that if I or someone else decide to implement the
"hardware offload" of requests ordering (ORDERED requests), I or he/she
would not be able to see any improvement until at least one file system
be changed to be able to use it. Worse, if the implementor can't
demonstrate the improvement, how can he encourage file systems
developers to update their file systems? Which, basically, would mean
that only a person with *BOTH* deep storage and file systems internals
knowledge can do the job. How many do you know such people? Both storage
and file systems topics are very wide and tricky, so nearly always
people specialize in one of them, not both.
Thus, this move would basically mean that the proper ordered queuing
would probably never be implemented in Linux.
I believe, much better would be to create a common interface, which file
systems would use to enforce requests order, when they need it.
Advantages of this approach:
1. The ordering requirements of file systems would be clear.
2. They would be handled in one place by a common code.
3. Any storage level expert can try to implement ordered queuing without
a deep dive into file systems design and implementation.
I already suggested such interface in
http://marc.info/?l=linux-scsi&m=128077574815881&w=2. Internally for the
moment it can be implemented using existing REQ_FLUSH/FUA/etc. and
waiting for all the requests in the group to finish. As a nice side
effect, if a device doesn't support FUA, it would be possible to issue
SYNC_CACHE command(s) only for required blocks, not for the whole device
as it is done now.
If requested, I can develop the interface further.
Vlad
next prev parent reply other threads:[~2010-08-13 12:55 UTC|newest]
Thread overview: 156+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-12 12:41 [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush Tejun Heo
2010-08-12 12:41 ` Tejun Heo
2010-08-12 12:41 ` [PATCH 01/11] block/loop: queue ordered mode should be DRAIN_FLUSH Tejun Heo
2010-08-12 12:41 ` Tejun Heo
2010-08-12 12:41 ` [PATCH 02/11] block: kill QUEUE_ORDERED_BY_TAG Tejun Heo
2010-08-12 12:41 ` Tejun Heo
2010-08-13 12:56 ` Vladislav Bolkhovitin
2010-08-13 13:06 ` Christoph Hellwig
2010-08-12 12:41 ` Tejun Heo
2010-08-12 12:41 ` [PATCH 03/11] block: deprecate barrier and replace blk_queue_ordered() with blk_queue_flush() Tejun Heo
2010-08-12 12:41 ` Tejun Heo
2010-08-14 1:07 ` Jeremy Fitzhardinge
2010-08-14 1:07 ` Jeremy Fitzhardinge
2010-08-14 9:42 ` hch
2010-08-16 20:38 ` Jeremy Fitzhardinge
2010-08-12 12:41 ` Tejun Heo
2010-08-12 12:41 ` [PATCH 04/11] block: remove spurious uses of REQ_HARDBARRIER Tejun Heo
2010-08-12 12:41 ` Tejun Heo
2010-08-12 12:41 ` Tejun Heo
2010-08-12 12:41 ` [PATCH 05/11] block: misc cleanups in barrier code Tejun Heo
2010-08-12 12:41 ` Tejun Heo
2010-08-12 12:41 ` [PATCH 06/11] block: drop barrier ordering by queue draining Tejun Heo
2010-08-12 12:41 ` Tejun Heo
2010-08-12 12:41 ` Tejun Heo
2010-08-12 12:41 ` [PATCH 07/11] block: rename blk-barrier.c to blk-flush.c Tejun Heo
2010-08-12 12:41 ` Tejun Heo
2010-08-12 12:41 ` Tejun Heo
2010-08-12 12:41 ` [PATCH 08/11] block: rename barrier/ordered to flush Tejun Heo
2010-08-12 12:41 ` Tejun Heo
2010-08-17 13:26 ` Christoph Hellwig
2010-08-17 16:23 ` Tejun Heo
2010-08-17 17:08 ` Christoph Hellwig
2010-08-18 6:23 ` Tejun Heo
2010-08-12 12:41 ` [PATCH 09/11] block: implement REQ_FLUSH/FUA based interface for FLUSH/FUA requests Tejun Heo
2010-08-12 12:41 ` Tejun Heo
2010-08-12 12:41 ` Tejun Heo
2010-08-12 12:41 ` [PATCH 10/11] fs, block: propagate REQ_FLUSH/FUA interface to upper layers Tejun Heo
2010-08-12 12:41 ` Tejun Heo
2010-08-12 12:41 ` Tejun Heo
2010-08-12 21:24 ` Jan Kara
2010-08-13 7:19 ` Tejun Heo
2010-08-13 7:47 ` Christoph Hellwig
2010-08-16 16:33 ` [PATCH UPDATED " Tejun Heo
2010-08-12 12:41 ` [PATCH 11/11] block: use REQ_FLUSH in blkdev_issue_flush() Tejun Heo
2010-08-12 12:41 ` Tejun Heo
2010-08-12 12:41 ` Tejun Heo
2010-08-13 11:48 ` [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush Christoph Hellwig
2010-08-13 13:48 ` Tejun Heo
2010-08-13 14:38 ` Christoph Hellwig
2010-08-13 14:51 ` Tejun Heo
2010-08-14 10:36 ` Christoph Hellwig
2010-08-17 9:59 ` Tejun Heo
2010-08-17 13:19 ` Christoph Hellwig
2010-08-17 16:41 ` Tejun Heo
2010-08-17 16:59 ` Christoph Hellwig
2010-08-18 6:35 ` Tejun Heo
2010-08-18 8:11 ` Tejun Heo
2010-08-20 8:26 ` Kiyoshi Ueda
2010-08-23 12:14 ` Tejun Heo
2010-08-23 14:17 ` Mike Snitzer
2010-08-24 10:24 ` Kiyoshi Ueda
2010-08-24 16:59 ` Tejun Heo
2010-08-24 17:52 ` Mike Snitzer
2010-08-24 18:14 ` Tejun Heo
2010-08-25 8:00 ` Kiyoshi Ueda
2010-08-25 15:28 ` Mike Snitzer
2010-08-27 9:47 ` Kiyoshi Ueda
2010-08-27 9:47 ` Kiyoshi Ueda
2010-08-27 13:49 ` Mike Snitzer
2010-08-30 6:13 ` Kiyoshi Ueda
2010-09-01 0:55 ` safety of retrying SYNCHRONIZE CACHE [was: Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush] Mike Snitzer
2010-09-01 7:32 ` Hannes Reinecke
2010-09-01 7:32 ` Hannes Reinecke
2010-09-01 7:38 ` Hannes Reinecke
2010-09-01 7:38 ` Hannes Reinecke
2010-12-08 21:14 ` [PATCH] scsi: improve description for deferred error Mike Snitzer
2010-12-28 21:45 ` Brett Russ
2010-08-25 15:59 ` [RFC] training mpath to discern between SCSI errors (was: Re: [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush) Mike Snitzer
2010-08-25 19:15 ` [RFC] training mpath to discern between SCSI errors Mike Christie
2010-08-30 11:38 ` Hannes Reinecke
2010-08-30 12:07 ` Sergei Shtylyov
2010-08-30 12:39 ` Hannes Reinecke
2010-08-30 12:51 ` Christophe Varoqui
2010-08-30 13:10 ` Hannes Reinecke
2010-08-30 14:52 ` [dm-devel] " Hannes Reinecke
2010-08-30 14:52 ` Hannes Reinecke
2010-10-18 8:09 ` Jun'ichi Nomura
2010-10-18 11:55 ` Hannes Reinecke
2010-10-19 4:03 ` Jun'ichi Nomura
2010-11-19 3:11 ` [dm-devel] " Malahal Naineni
2010-11-30 22:59 ` Mike Snitzer
2010-12-07 23:16 ` [RFC PATCH 0/3] differentiate between I/O errors Mike Snitzer
2010-12-07 23:16 ` [RFC PATCH v2 1/3] scsi: Detailed " Mike Snitzer
2010-12-07 23:16 ` [RFC PATCH v2 2/3] dm mpath: propagate target errors immediately Mike Snitzer
2010-12-07 23:16 ` Mike Snitzer
2010-12-07 23:16 ` [RFC PATCH 3/3] block: improve detail in I/O error messages Mike Snitzer
2010-12-08 11:28 ` Sergei Shtylyov
2010-12-08 15:05 ` [PATCH v2 " Mike Snitzer
2010-12-10 23:40 ` [RFC PATCH 0/3] differentiate between I/O errors Malahal Naineni
2011-01-14 1:15 ` Mike Snitzer
2011-01-14 1:15 ` Mike Snitzer
2011-01-14 1:15 ` Mike Snitzer
2011-01-14 1:15 ` Mike Snitzer
2011-01-14 1:15 ` Mike Snitzer
2010-12-17 9:47 ` training mpath to discern between SCSI errors Hannes Reinecke
2010-12-17 14:06 ` Mike Snitzer
2010-12-17 14:06 ` Mike Snitzer
2011-01-14 1:09 ` Mike Snitzer
2011-01-14 7:45 ` Hannes Reinecke
2011-01-14 13:59 ` Mike Snitzer
2010-08-24 17:11 ` [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush Vladislav Bolkhovitin
2010-08-24 23:14 ` Alan Cox
2010-08-24 23:14 ` Alan Cox
2010-08-13 12:55 ` Vladislav Bolkhovitin [this message]
2010-08-13 13:17 ` Christoph Hellwig
2010-08-18 19:29 ` Vladislav Bolkhovitin
2010-08-13 13:21 ` Tejun Heo
2010-08-18 19:30 ` Vladislav Bolkhovitin
2010-08-19 9:51 ` Tejun Heo
2010-08-30 9:54 ` Hannes Reinecke
2010-08-30 20:34 ` Vladislav Bolkhovitin
2010-08-18 9:46 ` Christoph Hellwig
2010-08-19 9:57 ` Tejun Heo
2010-08-19 10:20 ` Christoph Hellwig
2010-08-19 10:22 ` Tejun Heo
2010-08-20 13:22 ` Christoph Hellwig
2010-08-20 15:18 ` Ric Wheeler
2010-08-20 16:00 ` Chris Mason
2010-08-20 16:02 ` Ric Wheeler
2010-08-20 16:02 ` Ric Wheeler
2010-08-20 16:02 ` Ric Wheeler
2010-08-20 16:02 ` Ric Wheeler
2010-08-20 16:02 ` Ric Wheeler
2010-08-20 16:02 ` Ric Wheeler
2010-08-23 12:30 ` Tejun Heo
2010-08-23 12:48 ` Christoph Hellwig
2010-08-23 13:58 ` Ric Wheeler
2010-08-23 14:01 ` Jens Axboe
2010-08-23 14:08 ` Christoph Hellwig
2010-08-23 14:13 ` Tejun Heo
2010-08-23 14:19 ` Christoph Hellwig
2010-08-25 11:31 ` Jens Axboe
2010-08-30 10:04 ` Hannes Reinecke
2010-08-23 15:19 ` Ric Wheeler
2010-08-23 16:45 ` Sergey Vlasov
2010-08-23 16:45 ` [dm-devel] " Sergey Vlasov
2010-08-23 16:49 ` Ric Wheeler
2010-08-23 16:49 ` Ric Wheeler
2010-08-23 16:49 ` Ric Wheeler
2010-08-23 16:49 ` Ric Wheeler
2010-08-23 16:49 ` Ric Wheeler
2010-08-23 12:36 ` Tejun Heo
2010-08-23 14:05 ` Christoph Hellwig
2010-08-23 14:15 ` [PATCH] block: simplify queue_next_fseq Christoph Hellwig
2010-08-23 16:28 ` OT grammar nit " John Robinson
-- strict thread matches above, loose matches on Subject: below --
2010-08-12 12:41 [PATCHSET block#for-2.6.36-post] block: replace barrier with sequenced flush Tejun Heo
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=4C6540C5.8070108@vlnb.net \
--to=vst@vlnb.net \
--cc=James.Bottomley@suse.de \
--cc=chris.mason@oracle.com \
--cc=dm-devel@redhat.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=jaxboe@fusionio.com \
--cc=konishi.ryusuke@lab.ntt.co.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=rwheeler@redhat.com \
--cc=swhiteho@redhat.com \
--cc=tj@kernel.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 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.