🚀 go-pugleaf

In article <1993Jan11.233316.989@newscan.canada.sun.com>, dennis@zonzorp.Canada.Sun.COM (Dennis Simpson Sun Canada) writes:
> Maybe someone can save me digging up the answer.
> When we are talking about "losing data" on the nfs server when using
> the "evil asynch hack", are we talking about invisible loss? Or are we
> talking about "fsck removed this corrupt file during reboot"?
> 
> I suspect the former (invisible), and if this is true, how can anyone
> make the comment "we have had no problems using this hack"? Unless they
> truly believe the gods are watching over them.
> 
> Just curious,
> dennis
> 
> ---
> /---------------------------------------------------------------------\
> |  Dennis Simpson      dennis@canada.sun.com <at work>                |
> |                      daddy!dennis@zonzorp.canada.sun.com <at home>  |
> |  "I like the customer, in theory..."  - G. Rosser                   |
> \---------------------------------------------------------------------/
> 

I would like to think that the gods are watching me, but I don't think this
is the reason we have encountered no problems so far.

I think you are running *about* the same risk as when you do normal buffered
writes through the buffer-cache locally. Normally, the cache will be flushed
automagically every nth second by the the update process (or any equivalent) 
or by application generated sync() operations. 

If you for some reason experience a severe server crash between two flushes,
you are a candidate for data loss. In a filesystem local to the server, fsck
normally does a good job bringing the filesystem consistent again. So it does
with any server-exported filesystem. However, the important difference now is what 
happens on the remote client side before the remote application detects the
server failure. I imagine there are worst-case situations where both remote
pending unlink() and write() operations are involved, but I really don't know.

I would be happy to be corrected in the above assumptions by anyone more
knowledgable than me in this case. The assumptions are based on a rough
browsing through the source code for nfs_server.c on a SunOS 4.1.3 system.

 | Steinar Kjaernsroed	Dpt. of Informatics	email:steinar@ifi.uio.no
 |			University of Oslo,               or
 |                      NORWAY                        ..!mcsun!ifi!steinar