blob: 8914f93404e397bef39b2ce4b802d20710a1a9f2 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
|
.TH LOCKFS 4
.SH NAME
lockfs \- exclusive access file server
.SH SYNOPSIS
.B lockfs
[
.B -A
] [
.B -a
.I alg
]... [
.B -p
.I addr
]
.I dir
[
.I mountpoint
]
.SH DESCRIPTION
.I Lockfs
acts as a filesystem layer above an existing namespace,
allowing multiple-reader, exclusive writer access to the
files therein. Opening a file served by
.I lockfs
obtains a lock on the file, or blocks until a lock can
be obtained.
.I Lockfs
serves a single-level directory that initially contains the
files in
.IR dir .
If the
.B -p
option is provided,
.I lockfs
will listen for incoming connections on
.IR addr ,
authenticating them as required.
Each
.B -a
argument provides an acceptable
algorithm to run on the connection.
The list of all
.IR alg s
is passed to
.B server (see
.IR security-auth (2)).
If no
.B -a
arguments are given,
.B "-a none"
is assumed.
If the
.B -A
option is given, then no authentication
will be performed.
.PP
If the
.B -p
option is not given, the lockfs file system
will be mounted on
.IR mountpoint ,
or
.I dir
if
.I mountpoint
is not given.
.SH EXAMPLE
Run a lock server guarding access to
.BR /lib/datafiles :
.IP
.EX
lockfs -p 'tcp!*!32454' /lib/datafiles
.EE
.PP
Mount the above server (where
.I locksrv
was originally run on a server named
.IR machine .
.IP
.EX
mount -c tcp!\fImachine\fP!32454 /n/remote
.EE
.SH SOURCE
.B /appl/cmd/lockfs.b
.SH BUGS
There's no way to break a lock held by a
malingering process.
.PP
Should probably support multi-level directories.
|
