the bitrig pedro_softraid_flush branch has been created by pedro.

it is 2 commits behind master, and 5 commits ahead.

commit 4b46fe60939e68d56b13ee82b9edb4f90854108a
diff: https://github.com/bitrig/bitrig/commit/4b46fe6
author: Pedro Martelletto <[email protected]>
date: Thu Feb 26 11:28:07 2015 +0100

Handle DIOCCACHESYNC in softraid(4).

Handle DIOCCACHESYNC in softraid(4) by propagating the DIOCCACHESYNC
ioctl down to each of the physical disks composing the softraid(4)
volume.

M       sys/dev/softraid.c

commit 01bae7bd1faca88a64606b7acf8a84fdd58e3aa1
diff: https://github.com/bitrig/bitrig/commit/01bae7b
author: Pedro Martelletto <[email protected]>
date: Thu Feb 26 10:41:17 2015 +0100

Detect and handle DDIOCACHESYNC on softraid(4).

Detect DDIOCACHESYNC happening on softraid(4) and call a link specific
function to handle it. DDIOCACHESYNC results in a SCSI SYNCHRONIZE_CACHE
command, but SYNCHRONIZE_CACHE has different semantics on softraid(4)
than it does on physical disks.

Quoting ftp://ftp.t10.org/t10/document.05/05-344r0.pdf, page 63:

"The SYNCHRONIZE CACHE command requests that the device server ensure
that the specified logical blocks have their most recent data values
recorded in non-volatile cache and/or on the medium."

The understanding taken from this definition is that a SYNCHRONIZE CACHE
command should cause the I/O controller to dispose of any internal cache
it might have on /previously completed/ transactions.

What softraid(4) does when being issued a SYNCHRONIZE CACHE is to wait
for all /outstanding/ I/O to drain. This means that, even with the
previously described issues concerning parallel invocations of
sr_raid_sync() addressed, periodic use of DDIOCACHESYNC on a softraid(4)
disk backing a live file system imposes severe performance penalties.

M       sys/scsi/sd.c

commit 3c88a251a7f232ccb494eb1f3d5f91727d26b739
diff: https://github.com/bitrig/bitrig/commit/3c88a25
author: Pedro Martelletto <[email protected]>
date: Thu Feb 26 10:38:54 2015 +0100

Fix a memory leak in sr_ioctl_createraid().

Found while reading the code.

M       sys/dev/softraid.c

commit 4455973a77d93bffd78aa6e49d468684f060e0c4
diff: https://github.com/bitrig/bitrig/commit/4455973
author: Pedro Martelletto <[email protected]>
date: Thu Feb 26 10:34:21 2015 +0100

Initialise sd_scsibus_dev in sr_ioctl_createraid().

In sr_ioctl_createraid(), initialise sd_scsibus_dev with the 'struct
device' of the abstracted disk. This field was previously unused.

M       sys/dev/softraid.c

commit 6f4aa290a6f3c678ba5bbe70e7875dd08467d57d
diff: https://github.com/bitrig/bitrig/commit/6f4aa29
author: Pedro Martelletto <[email protected]>
date: Thu Feb 26 10:27:02 2015 +0100

Define and mark softraid(4) disks with SDEV_SOFTRAID.

In the same fashion of SDEV_{ATAPI,UMASS,VIRTUAL}, add a SDEV_SOFTRAID
flag and use it to allow the SCSI layer to identify disks abstracted
through softraid(4).

M       sys/dev/softraid.c
M       sys/scsi/scsiconf.h

Reply via email to