[illumos-Developer] MUCH better --> zil for zvol TRUNCATE (and iSCSI UNMAP) working...

George Wilson gwilson at zfsmail.com
Wed Mar 2 10:29:23 PST 2011


On 3/2/11 9:48 AM, Dan McDonald wrote:
> On Wed, Mar 02, 2011 at 09:18:02AM -0800, George Wilson wrote:
>>>>   Preserving this distinction in the API seems appropriate, but there's no
>>>> reason to call txg_wait_synced() in the zvol implementation.
>>> You mean preserving DF_WAIT_SYNC?  Or SL_WRITEBACK_CACHE_DISABLED?
>>>
>>> I'll take out the txg_wait_synced() call.
>> Sorry guys, I feel behind on this thread.
>>
>> The one thing that the txg_wait_synced() provides is for callers to
>> wait for all the blocks to be freed before continuing. I don't know
>> if this is a requirement or not.
> Your description of txg_wait_synced() behavior does match up with the
> WRITEBACK_CACHE_DISABLED, but Eric points out:

I see 3 slightly related controls for DKIOCFREE:

1). is write-cache enabled (ZVOL_WCE)?
2). is sync-always enabled (ZVOL_SYNC_ALWAYS)?
3). do you want to wait for the frees to complete (DF_WAIT_SYNC)?

I see 1 and 2 above as ways to control whether or not a zil_commit() is 
required as part of the free. I see #3 as way to control do you want the 
operation to not return until the free is complete and all metadata has 
been updated.

My initial comments (long time ago) mentioned that this operation should 
always be log to the zil. If we want to honor 
SL_WRITEBACK_CACHE_DISABLED then we should make the zil_commit() 
optional based on #1 and 2.
>>>> It's not clear to me how a consumer
>>>> could recover from "lost" frees.  For the zvol implementation this is all
>>>> moot, but we can start with your interpretation and adapt it as necessary
> I wonder if the principal of least surprise might apply here?  That would
> argue for implementing DF_WAIT_SYNC by using txg_wait_synced().

I think there is a need for a "wait" flag and maybe there's a need to 
have all three flags for completeness.

- George
> Dan
>
> _______________________________________________
> Developer mailing list
> Developer at lists.illumos.org
> http://lists.illumos.org/m/listinfo/developer




More information about the Developer mailing list