[stgt] [PATCH] SSC: dont fsync() on each written block. Do one single fsync() when file is closed in FILEMARK

ronnie sahlberg ronniesahlberg at gmail.com
Mon Jan 23 02:49:49 CET 2012


It is fine to not fsync() on write   but we should indicate we do so
by setting the proper "buffered-mode" in the device specific part of
mode sense.


>From SSC :



6.9 WRITE-FILEMARKS(6)
---
NOTE 37 Upon completion of any buffered write operation, the
application client may issue a WRITE
FILEMARKS(6) command with the IMMED bit set to zero and the FILEMARK
COUNT field set to zero to perform a
synchronize operation (see 4.2.10).
---

This indicates that writes may be buffered and to volatile memory only.
But when the WRITE-FILEMARK command is issued, this forces all data to
be written and synchronized to tape
even if the filemark count is zero. So that means we can do the fsync() here.


8.3.1 MODE PARAMETERS OVERVIEW
TABLE 90 - DEVICE-SPECIFIC PARAMETER
---
1h

The device server may report GOOD status on WRITE commands as soon as
  all the data specified in the WRITE command has been transferred to
the logical
 unit’s object buffer. One or more logical blocks may be buffered
prior to writing
  the logical block(s) to the medium.
---
Which means that since we do buffered writes, we should indicate this
to the initiator by setting
BUFFERED-MODE to 1.



So, doing this is fine according to SSC, but we have to indicate that
we do this by setting the buffered-mode to 1h in the mode-sense data.
I have attached an updated patch that both does the "fsync() on
write-filemark" as before but also modifies the mode-sense we send
back from ssc devices to indicate "buffered-mode==1 : we do buffered
writes."



regards
ronnie sahlberg


On Mon, Jan 23, 2012 at 10:01 AM, FUJITA Tomonori
<fujita.tomonori at lab.ntt.co.jp> wrote:
> On Sun, 22 Jan 2012 07:59:03 +1100
> ronnie sahlberg <ronniesahlberg at gmail.com> wrote:
>
>> Thanks Mark,
>>
>> That was my understanding from the SSC spec too, though I am not a tape guy.
>>
>>
>> So, this means that the behaviour in the patch is standards compliant,
>> and also what physical devices do.
>> Destage to physical medium is only guaranteed to be completed once the
>> WRITE-FILEMARK has finished.
>>
>>
>> So we dont need to add any controls to activate/deactivate this new behaviour.
>> We can just apply the current patch as-is  and that is all we need to do.
>
> I'd love the patch, but can anyone give me a pointer in the spec,
> please.
>
>
> Thanks,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Update-bs_ssc.c-to-only-fsync-on-the-final-WRITE-FIL.patch
Type: text/x-diff
Size: 2080 bytes
Desc: not available
URL: <http://lists.wpkg.org/pipermail/stgt/attachments/20120123/f7c86690/attachment-0002.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Update-bs_ssc.c-to-only-fsync-on-the-final-WRITE-FIL.patch.gz
Type: application/x-gzip
Size: 924 bytes
Desc: not available
URL: <http://lists.wpkg.org/pipermail/stgt/attachments/20120123/f7c86690/attachment-0002.bin>


More information about the stgt mailing list