Date: Tue, 10 Nov 1998 19:57:31 -0700 (MST) From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: hackers@FreeBSD.ORG Subject: Re: SCSI tagged queueing and softupdates Message-ID: <199811110257.TAA28938@narnia.plutotech.com> In-Reply-To: <98Nov11.084659est.40344@border.alcanet.com.au> <199811102247.OAA16696@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199811102247.OAA16696@apollo.backplane.com> you wrote: > :According to the description, tagged queueing allows a SCSI device to > :re-order pending I/O requests in order to improve throughput. Soft > :updates, on the other hand, rely on the correct sequencing of physical > :writes to ensure that the disk metadata is consistent. > : > :Is this a real issue? If so, it would seem that tagged queueing must > :be disabled (at least for writes) when softupdates are enabled. It's > :not obvious to me that this is currently done (or even easy to do). > : > :Comments please. > : > :Peter > > No, this is not an issue. Correct. > The SCSI command set allows you to flag > tags for ordered sequencing. Yes, but softupdates does not make use of this mechanism even though, via 'bowrite' it could. Instead softupdate sends batches of writes that do not have interdependencies and waits for them to complete before sending the transactions that depend on their completion. In many workloads, due to the async and distributed nature of the writes performed by the softupdates code, there is little need to use ordered writes. In the case of certain database applications that rely on fsync or when the dependency state grows large enough to hit its high resource watermark and state needs to be flushed quickly, I believe that ordered writes could significantly improve the performance of softupdates. I haven't had a chance to talk to Kirk about this yet. > Write ordering is a more > complex issue and I think (?) they are all simply flagged to be ordered. Writes are allowed to complete out of order unless the buffer client explicitly requests an ordered write. In previous BSD implementations the client had no control over ordering and could assume that the device driver might perform elevator or other sorting on any requests. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811110257.TAA28938>