ZFS dataset property to support SMB [PSARC/2009/140 FastTrack timeout 03/05/2009]
Alan M Wright
amw at sun.com
Mon Mar 2 19:00:50 PST 2009
On 02/28/09 00:25, Cyril Plisko wrote:
> Hi Alan,
>
>> All shares of a dataset should report the same label and drive letter,
>> and I should be able to set sharesmb=off and still have other shares
>> report that drive letter and label.
>
> I see what you mean.
>
>> For example:
>>
>> zfs create -o casesensitivity=mixed tank/photos
>> zfs sharesmb=off
>>
>> sharemgr create -P smb photogroup
>> sharemgr add-share -r public -s tank/photos/public photogroup
>> sharemgr add-share -r private -s tank/photos/private photogroup
>>
>> I now have two shares (public and private) and sharesmb=off.
>>
>> If I were to set a label using sharesmb that would cause zfs to share
>> tank/photos, which I may not want shared.
>
> I do not understand that.
Assuming that we were to use sharesmb to set the label and that we
already have the public and private shares defined ...
zfs sharesmb=label=images
Now I have three shares: public and private and tank_photos.
All report the label as images.
But I don't want tank_photos shared, so I do:
zfs sharesmb=off
Now I have two shares (public and private) but the label for those
two shares has silently changed to photos.
The sharesmb syntax will not allow me to set sharesmb to off AND
set other options.
> Why wouldn't you just set label with sharemgr than ?
sharemgr deals with a share or share groups but it has no mechanism
to apply something to all shares or to remember that something has
been set and must be applied to all future shares. Just like the
case-sensitivity of the file system, these new settings must be
persistent even if I delete all shares (and all share groups), turn
all sharing off and then create new shares. Sharemgr also has no
means to manage properties across zfs send/receive or export/import.
>> The current syntax doesn't allow sharesmb=off,label=photos, and if we
>> change the syntax of sharesmb it would be inconsistent with sharenfs and
>> shareiscsi.
>
> To the contrary - sharenfs does allow such syntax, and it is widely used:
>
> pronto:/home/imp> zfs get sharenfs tank/export/install
> NAME PROPERTY VALUE SOURCE
> tank/export/install sharenfs ro,anon=0 local
You can specify multiple options but "off" cannot be combined with
other options:
shareiscsi=on | off
sharenfs=on | off | opts
sharesmb=on | off | opts
>> Suppose I did want to share tank/photos and set some options:
>>
>> zfs sharesmb=name=photos,csc=auto,oplocks=disabled,label=z:photos,
>>
>> Here you would be applying name and csc to the tank/photos share but not
>> to the public and private shares, but the oplocks and label values would
>> apply to the public and private shares. It may cause confusion to mix
>> share specific options with dataset wide options in this format.
>
> I do not see how can it causes any confusion. To my understanding it
> does exactly what you want, but may be I missing something here.
Perhaps because I explained them here but to someone new to ZFS and
sharesmb the only way to know what that command does is to study the
man page - very carefully. It is very easy to make mistakes and not
get the behavior you expect.
> Anyway, why don't we just always use "final component of the
> mountpoint property" as you've suggested and need a special attribute
> to override the value ?
That's explained in the ARC materials. Some Windows applications
track removable and remote volumes via their volume labels and embed
the volume label in on-disk databases. If you move the database to
another volume or do anything that changes the volume label reported
to the application, you will be unable to access your data. The
data can be made accessible by renaming the current volume label.
> After all windows users do not have an option
> to report volume label other than it is set on the disk.
Windows users can set the label to anything they want - except for
a few excluded characters.
The label command can be used to change the label on a Windows file
system.
Alan
More information about the opensolaris-arc
mailing list