1 |
All, |
2 |
|
3 |
This is my previous post, added on the right thread this time. |
4 |
|
5 |
as I have always said, my views can evolve with civil discussion, and |
6 |
there has been some good feedback on this. |
7 |
|
8 |
I also got a suggestion for handling network file systems that would mean we |
9 |
wouldn't have to keep track of the specific clients needed to mount |
10 |
network file systems; we could let the distros tell us what the network |
11 |
file system types are and which services should be started to support |
12 |
them. |
13 |
|
14 |
Look at the new-netmount branch for that. Basically it would be a series |
15 |
of files in a directory which would have the name of a filesystem type |
16 |
as their file name, then inside each file, the name of the service that |
17 |
supports them. |
18 |
|
19 |
The point of debate I suppose is the dependency type that should be used |
20 |
for these. On the branch it is use, which requires you to add the |
21 |
appropriate service to the runlevel netmount is in, but some want it to |
22 |
be want once it is implemented. |
23 |
|
24 |
Also, I want to talk more about netmount and localmount failing. |
25 |
|
26 |
If netmount and localmount are set up to fail if one of the file systems |
27 |
they mount fails (which is what other init systems out there do), the |
28 |
sys admin can control whether the mount -a command cares about the |
29 |
status of specific file systems by adding nofail to the mount options in |
30 |
fstab. By default it would care, but if you add nofail to the mount |
31 |
options, you would affectively tell mount -a to not be concerned about |
32 |
whether the mount succeeds or not. |
33 |
|
34 |
Thoughts? |
35 |
|
36 |
William |
37 |
> |