https://bugzilla.novell.com/show_bug.cgi?id=331255 Stephan Binner changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Usability |Basesystem -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=331255 Cyril Hrubis changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chrubis@novell.com AssignedTo|bnc-team-screening@forge.provo.novell.com |ro@novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=331255 User brian@clusterfs.com added comment https://bugzilla.novell.com/show_bug.cgi?id=331255#c4 Brian Murrell changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | --- Comment #4 from Brian Murrell 2008-02-14 11:08:40 MST --- (In reply to comment #3 from Ruediger Oertel)

other network filesystems are normally mounted by their respective rc-scripts, e.g. nfs,smbfs,autofs,open-iscsi,...

Has NFS really gotten that complicated that it needs its own rc script? For a long time, NFS has been able to use _netdev in /etc/fstab to simply delay mounting until the network was available.

Since the requirements of these filesystems vary from type to type it would not make too much sense to have a generic version to "catch all" network filesystem mounting.

Do you maintain that position even for network filesystems whose only requirement is that the network be available? It seems silly to have an initscript that simply does: mount -t <fstype> -a That is simply placed after or dependent on the network start initscript.

SLES9 for example had a package lustre-lite with the rcscript /etc/init.d/lustrefs taking care of mounting this type of filesystem.

Heh. You must have chosen the lustre-lite/lustrefs example for a reason. :-) Indeed, in the SLES9 days, yes, Lustre had it's own tools to bring up the filesystem. We went to great pains to eliminate that initscript and work with standard tools such as mount, mkfs, and tunefs. Now Lustre, on all servers and clients can be mounted with nothing more complicated than an /etc/fstab entry, IFF that entry can be dependent on the network being up, which historically is what the _netdev fstab option was for. I'm getting a feeling though, that no matter what I say you won't rethink your abolishment of _netdev or any other facility that allows /etc/fstab entries to delay mounting until after the network is up. Is that true? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=331255 User brian@clusterfs.com added comment https://bugzilla.novell.com/show_bug.cgi?id=331255#c6 --- Comment #6 from Brian Murrell 2008-02-15 15:45:36 MST --- (In reply to comment #5 from Ruediger Oertel)

not really ;)

:-(

yes, I'd consider this a _new_ feature to have a generic network filesystem mount script.

This "_new_" feature is what has been in the likes of RHEL (and other distros) for ever and known as "netfs": # netfs Mount network filesystems. # # Authors: Bill Nottingham # AJ Lewis # Miquel van Smoorenburg, .. NFSFSTAB=`LC_ALL=C awk '!/^#/ && $3 ~ /^nfs/ && $3 != "nfsd" && $4 !~ /noauto/ { print $2 }' /etc/fstab` SMBFSTAB=`LC_ALL=C awk '!/^#/ && $3 == "smbfs" && $4 !~ /noauto/ { print $2 }' / CIFSFSTAB=`LC_ALL=C awk '!/^#/ && $3 == "cifs" && $4 !~ /noauto/ { print $2 }' / NCPFSTAB=`LC_ALL=C awk '!/^#/ && $3 == "ncpfs" && $4 !~ /noauto/ { print $2 }' / NETDEVFSTAB=`LC_ALL=C awk '!/^#/ && $4 ~/_netdev/ && $4 !~ /noauto/ { print $1 } NFSMTAB=`LC_ALL=C awk '!/^#/ && $3 ~ /^nfs/ && $3 != "nfsd" && $2 != "/" { print SMBMTAB=`LC_ALL=C awk '!/^#/ && $3 == "smbfs" { print $2 }' /proc/mounts` CIFSMTAB=`LC_ALL=C awk '!/^#/ && $3 == "cifs" { print $2 }' /proc/mounts` NCPMTAB=`LC_ALL=C awk '!/^#/ && $3 == "ncpfs" { print $2 }' /proc/mounts` NETDEVMTAB=`LC_ALL=C awk '!/^#/ && $4 ~ /_netdev/ && $2 != "/" { print $2 }' /et That one script mounts cifs, nfs, ncpfs and _netdev flagged filesystems.

On the other hand, given current development with dynamic network devices, sysv-initscripts that need the network first might be a thing of the past and might fade away again soon.

Well, upstart really is pushing in that direction, indeed. But I think we are a ways away from seeing the reality of that in the real world. In the meanwhile we will continue to need initscripts.

For SLE10 this might still be an option however, at least on SLES the ifconfig method of bringing up network devices is still the default there.

As it is for every other distro I have my fingers on.

Sure I chose lustre-lite for a reason, but that list can easily be expanded to smbfs/cifs, ocfs, iscsi, ....

netfs in RHEL4 seems to achieve the goal without a separate script for every network filesystem. I don't have RHEL5 to see how they are maintaining that in the modern world though.

The nfs client script is probably the most primitive one from these examples, all we do is check if /usr or /opt is in the list of newly mounted filesystems and run ldconfig afterwards (which would be a pretty generic thing as well).

But where do NFS client mounts actually happen in system init? Surely they are not part of the localfs mounts are they? Do you have network up before you do localfs mounts? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=331255 Ruediger Oertel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |ASSIGNED Priority|P5 - None |P4 - Low -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.