Date: Fri, 10 Jun 2005 04:05:52 -0400 (EDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: arch@FreeBSD.org, Pawel Jakub Dawidek <pjd@FreeBSD.org> Subject: Re: simplify disksort, please review. Message-ID: <20050610040302.S16943@mail.chesapeake.net> In-Reply-To: <9131.1118346135@critter.freebsd.dk> References: <9131.1118346135@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 9 Jun 2005, Poul-Henning Kamp wrote: > In message <20050609193008.GB837@darkness.comp.waw.pl>, Pawel Jakub Dawidek writes: > > >The one example of how the order can be broken (write(offset, size)): > > > > write(1024, 512) > > write(0, 2048) > > If you issue these two requests just like that, you get no guarantee > which order they get written in. > > It's not just disksort which might surprise you, tagged queuing and > write caches may mess up your day as well. Through the filesystem the buf will be locked until the first write completes. Truthfully, it's likely to be DELWRI, which means the second write will be a memcpy into the buffer. If you fsync'd between the two, the first could still be in the drive cache when the second comes down, but certainly the drive cache will remain coherent. Anyway, it's really not important to solve at the disk queue layer, because it's only an issue with raw devices, and it's very irregular to have multiple processes opening the same raw device to issue a lot of io of different sizes. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050610040302.S16943>