Asynchronous writing to zvols (ZFS)

[Pawel Jakub Dawidek]

On Sun, Jul 27, 2008 at 08:26:46PM +0200, Peter Schuller wrote:
> Hello,
> 
> > The problem is that we don't between async and sync I/O request on GEOM
> > level, that's why I decided to commit a ZIL log after each write, which
> > wasn't very smart it seems. This is handled differently in version I've
> > in perforce. Could you try the below patch and see how it performs now?
> >
> > 	http://people.freebsd.org/~pjd/patches/zvol.c.patch
> 
> The above (though the files has moved, for anyone else reading wanting to 
> apply) does eliminate the synchronicity problem. I am now seeing 5-15 
> MB/second write speeds to the zvol, with 100% constituent disk utilization.
> 
> I am not sure why I don't see faster writes; I get more like 40-60 when 
> writing to a file in a ZFS file system on the same pool. But regardless, the 
> synchronisity issue is gone.

Not sure why's that, I spent no time on optimizing ZVOL yet, sorry.

> Does your comment above regarding distinguishing bewteen sync and asynch apply 
> to the section of code affected by the above patch, or did you mean there is 
> some other place above the zvol handling where there is lack of distinction?
> 
> That is, is the end-effect of the above change that we *never* do synchronous 
> writes (because the fact that a write is supposed to be synchronous is 
> somehow lost before it reaches that point)?
> 
> I understand a zil_commit is only required on BIO_FLUSH requests, which is 
> what the patch fixes. But I get the impression from your phrasing above that 
> the reason that a zil_commit was done on every I/O from the get go was in an 
> effort to honor actual synchronous writes by conservatively *always* doing 
> synchronous writes, because the synchronicity of synchronous writes would not 
> be propagated down to the zvol class. I wouldn't want to sacrifice 
> correctness just to get the speed ;)

With the patch above we synchoronize in-memory transactions every 5
seconds or when queue is full or when we receive BIO_FLUSH. Of course
the previous behaviour was more conservative, but sending writes down
doesn't mean they will reach disk platters. There is still disk cache in
the way. If we really want to be sure that data is safe on the disk, we
should send BIO_FLUSH. In other words if you use UFS on raw disk, sync
writes can still be delayed by disk's cache. When you use UFS on top of
ZVOL, writes can be delayed by ZFS cache.

I think the way to go is to pass sync/async property of I/O request down
to the GEOM stack.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20080806/d8205c13/attachment.pgp