samba - Feb 2016 - vfs_shadow_copy2: unmount snapshot while user is restoring from it

Hi Uri,
Thanks for your response.

We do not want to delete the share in smb.conf and later to
reconfigure it without the shadow copy. We want to keep the shadow
copy and rotate the snapshots. For example, we want to keep 24 hourly
snapshots, and every hour we create a new snapshot and unmount the
oldest one. But since customers can be restoring from the oldest
snapshot right now, it is not deterministic when we will be able to
unmount the oldest snapshot. So at that moment we want all active
restore operations to abort with an error, and then we unmount. Like I
mentioned, failing shadow_copy2_fstat operation (for example)
partially achieves what we need. But we will have to do custom code
changes in the shadow copy module.

However, this problem should be common to all storage vendors using
the shadow copy module with mounted snapshots. Do you know by chance
what other storage vendors do to cope with it?

Thanks,
Alex.



On Tue, Feb 9, 2016 at 8:27 PM, Uri Simchoni <uri at samba.org>
wrote:
> Only thing I know of that works for sure is kill smbd and wait for it to
> terminate before trying to unmount.
>
> Some clever mix smbcontrol/smbstatus might work too, e.g. deleting the
share
> in smb.conf, sending smbd a message to reload config, sending smbd a
message
> to disconnect all tree-connects to shares that might have snapshots,
waiting
> till smbstatus shows no connections to those shares (or till lsof shows no
> files open on the snapshot), then unmounting, then re-adding the share
> without the shadow copy and reloading config.
>
> The challenge is getting smbd to close connection and being sure that it
> indeed closed them.
>
> I hope that helps,
> Uri.
>
>
> On 02/08/2016 06:22 PM, Alex Lyakas wrote:
>>
>> Greetings,
>>
>> I am trying to use vfs_shadow_copy2 with samba samba-4.2.7.
>>
>> I have a share exported at /export/smb400/. A snapshot of the share is
on
>> a separate block device, which is mounted at
>> /export_shadows/volume-00000001/@GMT-2016.02.08-11.48.00/. Samba
>> configuration for the share is:
>>
>> vfs objects = shadow_copy2
>> shadow:snapdir = /export_shadows/volume-00000001
>> shadow:fixinodes = yes
>>
>> (Note: I had to pull two patches by Uri Simchoni to make the snapshots
>> mounted outside of the share working [1] and [2]).
>>
>> Everything is working fine, and on Windows the “Previous version"
tab
>> allows to restore files from the snapshot.
>>
>> However, when a large file (say 10GB) is being restored, during that
time
>> it is not possible to unmount the snapshot block device, because Samba
is
>> holding open file descriptors on its mount point. Question: is there a
way
>> to forcefully unmount the snapshot block device, such that all ongoing
>> Restore operations will fail?
>>
>> I did some debugging and saw that during the Restore process
>> shadow_copy2_fstat() is being called a lot (by
>> smb_vfs_call_copy_chunk_send). So I tried to return a failure in this
>> function (-1 with errno=ENOENT). I saw that it indeed helps: Restore
>> operation hits an error. But it takes about 10 seconds, until unmount
of the
>> snapshot finally succeeds.
>>
>> My question is: is there any other operation in “vfs_fn_pointers” that
I
>> can implement or fail to make vfs_shadow_copy2 quickly close all open
file
>> descriptors, such that unmount of the snapshot succeeds?
>>
>> Thanks,
>> Alex.
>>
>> [1]
>> vfs_shadow_copy2: add shadow_copy2_do_convert()
>> [2]
>> vfs_shadow_copy2: fix case where snapshots are outside the share
>>
>>
>>
>