I should add that sharefs here is only acting as a pass through between
libshare in userspace and protocol services in the kernel. It provides,
two commands for publishing/unpublishing (sharing/unsharing). Since
sharefs is just a pass through, semantics of these commands are of
libshare + protocol service concern and not sharefs.
Afshin
On 05/ 5/10 12:30 PM, Afshin Salek wrote:
This might have been specified in libshare V2 design document but the
current behavior is unpublish followed by publish.
Afshin
On 05/ 5/10 07:04 AM, Pavel Filipensky wrote:
In case of the re-sharing (sharing with different options) - will the
libshare
issue two syscalls - SHAREFS_UNPUBLISH followed by SHAREFS_PUBLISH?
Or just a SHAREFS_PUBLISH will be issued?
I am asking because the current interfaces are not explicit about the type
- they do not specify if it is a share or a re-share.
It seems that also this proposal is not explicit about that.
<snip from "6930814 share/unshare issues">
SHARE versus RESHARE
The interfaces are not explicit about the type - it is a share or a re-share?
Neither the caller (libshare) specifies if it is doing a share/re-share,
nor the kernel (nfssrv/sharefs) reports back in the return value if it has
done a share or a re-share.
</snip>
Pavel
On 05/05/10 00:25, Tim Haley wrote:
I am sponsoring the following fast-track for Afshin Salek. This
proposal condenses the pair of syscalls used independently for sharing
nfs and cifs into one syscall. Requested binding is Micro/Patch.
Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
This information is Copyright (c) 2010, Oracle and/or its affiliates.
All rights reserved.
1. Introduction
1.1. Project/Component Working Name:
Unified sharing system call
1.2. Name of Document Author/Supplier:
Author: Afshin Salek
1.3 Date of This Document:
04 May, 2010
4. Technical Description
4.1. Details
Currently, two system calls and a door are used to publish shares: the
nfsys multi-purpose system call to export NFS shares, the sharefs system
call to update sharetab and an smbd door to publish SMB shares. libshare
has to call the NFS or SMB service once per file system and then it has
to call sharefs once per share, which results in 1000's of system calls
to publish 1000's of shares.
This is a proposal to unify all file sharing via a single system call:
sharefs. It is also to support of PSARC 2010/124 (libshare V2), which
requires changes to NFS, SMB and ZFS.
Publishing all shares via a single system call has several advantages:
simplifies libshare, significantly reduces the number of system calls
per file system and per share, and improves integration between sharetab
and the protocol services. Libshare will call sharefs once per file
system (for each protocol that has something to share) with a list of
shares and the protocol services will update sharetab by making calls
to an in-kernel sharefs API. There will be no user space interface to
update sharetab directly.
Having the protocol services update the sharetab file has two advantages
for libshare and sharefs: it significantly reduces the number of system
calls, as explained above, and neither libshare nor sharefs need to
perform per share error handling. Each protocol service handles its own
[un]publish operations and is responsible for updating sharetab as
appropriate. There is no need for the protocol services to return a list
of individual share results.
The sharefs system call would be changed to accept: a protocol
discriminator
(NFS or SMB), an operation (publish or unpublish) and an opaque
pointer to
share data. The opaque data passes transparently through sharefs between
the protocol-specific libshare plugin and the protocol service per PSARC
2010/124. The new prototype for sharefs would be of the form:
int sharefs(sharefs_proto_t proto, sharefs_op_t opcode,
void *data, size_t datalen);
Where:
typedef enum sharefs_proto {
SHAREFS_NFS,
SHAREFS_SMB
} sharefs_proto_t;
typedef enum sharefs_op {
SHAREFS_PUBLISH,
SHAREFS_UNPUBLISH
} sharefs_op_t;
Sharefs would be changed from a dynamically loaded module to be part of
the kernel. When invoked via the system call, sharefs would dynamically
load the NFS or SMB module as required and call the appropriate op
(publish or unpublish) registered by the module. The implication being
that each protocol service would register an op table with sharefs at
load time and that sharefs would provide an in-kernel API to update
sharetab. Each protocol service would be responsible for calling the
sharetab API as shares are added or removed.
The nfssys system call will no longer handle [un]sharing of NFS shares:
EXPORTFS support will be removed from nfssys_op.
The in-kernel sharefs API would be:
typedef int (*sharefs_sop_t)(sharefs_op_t opcode,
void *data, size_t datalen);
int sharefs_register(sharefs_proto_t proto, sharefs_sop_t sop);
Register with sharefs to receive calls to publish or unpublish
shares. If sop is a non-NULL pointer the function will
be registered as the handler for the specified protocol.
If sop is NULL, the handler for the specified protocol
will be set to NULL, effectively unregistering the service.
Return values:
0 success
EINVAL Unknown protocol.
typedef struct share {
struct share *sh_next;
char *sh_path; /* share path */
char *sh_resource; /* share name */
char *sh_fstype; /* protocol string ("nfs" | "smb") */
char *sh_opts; /* share property string */
char *sh_descr; /* share description */
size_t sh_size;
} share_t;
int sharetab_add(share_t *share);
Add an entry to sharetab. Existing entries are replaced
with the new entry. All data is copied to sharetab.
Return values:
0 success
EPERM permision denied
int sharetab_remove(share_t *share);
Remove an entry from sharetab. The parameter must contain
enough information to uniquely identify a sharetab entry.
For NFS: sh_fstype and sh_path
For SMB: sh_fstype and sh_resource.
Return values:
0 success
ENOENT entry not found in sharetab
EPERM permision denied
4.2 Bug/RFE Number(s):
6850837
4.5 Interfaces
_______________________________________________________________
| Exported Interface | Classification | Comments |
|________________________|___________________|__________________|
| sharefs sys-call | Consolidation | Consumed by |
| | Private | libshare |
| | | |
| sharefs_register | Consolidation | Consumed by NFS |
| | Private | SMB modules |
| | | |
| sharetab_add | Consolidation | sharefs kernel |
| sharetab_remove | Private | API to manage |
| | | sharetab content |
|________________________|___________________|__________________|
4.6. Doc Impact:
N/A
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
_______________________________________________
opensolaris-arc mailing list
[email protected]
_______________________________________________
opensolaris-arc mailing list
[email protected]
