Hi,

thank you all for the discussion.  

> /home directories is a classic example to have it hard or soft
> mounted ... there seem to be good points to doing it both ways..

The statement above was the main reason why I asked my question.
We use NFS to mount the /home directories as well as some /Data partitions 
where users can write the output data of their computer simulations. 



>Basically, the difference between "hard" and "soft" is:
>
>* "hard" -- "I need this filesystem"
>-> If this filesystem becomes unavailable you will hang until it is
>available again, but when it comes back you will not have lost data,
>unless something really weird happened on the server side, *or* your own
>system lost power or was otherwise rebooted.
>
>* "soft" -- "I don't really need this"
>-> If this filesystem becomes unavailable you will lose any unsaved data
>in fairly short order, but your own system will continue to function.

I was wondering, whether there would be any more damage to the fs if a 
connection died than just one corrupted file. 
Hence, I guess, I will mount the partitions soft, so to just spoil the job of 
one user and still having the network up and running for all the other folks.

Thanx!

Hauke


> hi ya peter...
>
> **oops... maybe i should have added a few more assumptions..
>       - i think the results would vary depending on what happened
>        to make the remote fs go offline
>
> if the remote hard mounted system goes down for some reason
> ( power failure, reboot, etc...
>       - than you lose data on the remote machine
>
> if the admin simply disconnected the remote machine ethernet
> cable and move it to another port, nothing is lost if
> they reconnect it in time ...
>       - but you do wait till the remote fs come back online
>
> the remote fs can also become unavailable because someobody
> stopped autofs  and try to restart ... ( a bad thing to do
> when the remote fs is in use ( say /home is a good example ) ..
> but people get into odd positions ...
>       - cant login or ls or anything and gets worst when
>       somebody decides to restart the automounters
>
>       - lots of whacky stuff... time to a good network policy
>
> i think/claim you lose unsaved data for hard or soft mounts
> if the remote fs does not come back in time ... also, you might
> have to unlock the file for more editing depending
> on which editor you used ( local or remote editor ) to edit the
> files before the remote fs went "temporarily offline"
>
> for hardmounts... the commands that access the remote fs
> has to sit and wait... and if not interruptable, you cant
> kill the hung job either.... and more and more commands
> might get hung ( df, ls /remote_fs/... etc ) and your pc gets
> slower and slower...
>       - am assuming hardmounts are interruptable...
>       some are ..some are not...
>
>       ls /remote_fs/*  on a remote server will hang till
>       it comes back... but should be interruptable
>
> i like soft mounts.... since i do lots of df and ls commands
> across many machines
>
> /home directories is a classic example to have it hard or soft
> mounted ... there seem to be good points to doing it both ways..
>
> -- well..anyway... i agree with you peter..
>
> have fun linuxing
> alvin
>
> On Wed, 28 Nov 2001, H. Peter Anvin wrote:
> > [EMAIL PROTECTED] wrote:
> > > when the remote fs goes down for more than a few seconds... you're dead
> > > anyway... dont matter ...
> > >   - you will lose the edits you did not save ...
> >
> > Baloney.
> >
> > Basically, the difference between "hard" and "soft" is:
> >
> > * "hard" -- "I need this filesystem"
> > -> If this filesystem becomes unavailable you will hang until it is
> > available again, but when it comes back you will not have lost data,
> > unless something really weird happened on the server side, *or* your own
> > system lost power or was otherwise rebooted.
> >
> > * "soft" -- "I don't really need this"
> > -> If this filesystem becomes unavailable you will lose any unsaved data
> > in fairly short order, but your own system will continue to function.
> >
> >     -hpa

Reply via email to