Date: Sat, 12 Jul 1997 18:21:03 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: Chuck Robey <chuckr@glue.umd.edu> Cc: freebsd-SCSI@FreeBSD.ORG, filo@yahoo.com, dg@root.com Subject: Re: problems with reboot Message-ID: <XFMail.970712182103.Shimon@i-Connect.Net> In-Reply-To: <Pine.BSF.3.96.970712151441.28420C-100000@Journey2.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Chuck Robey; On 12-Jul-97 you wrote: ... > > Under normal operation, it generates the SCSI ``ALLOW MEDIA REMOVAL'', > > which the DPT blocks until it is done flushing and invalidating. > > I personally never have this problem on any of our machines, but... > > Is this always safe? I've had some instances where a umount call simply > hung, and never returned. I think they were either nfs or msdos mounts > that gave this trouble, but the umount call could not be kill'ed, and > making shutdown wait? Would halt still work, as an emergency measure? > I know the FSs that were hung wouldn't be closed, but at least my ufs FSs > would be clean. Network Failure system is a special case (i AM being nice :-); It is supposedly stateless and the mount is a client and thus not governing physical I/O. a shutdown can (should) probably force a umount. Even on a local system, a forced umount is OK. It is a FS issue. But if the fs layer calls a function that by definition blocks, it is ``none of the caller's business'' how/what the callee does and how long it takes. To assume anything on the nature if a callee's internals is not a good idea. Here we have a live exapmple (why it is a bad idea). Simon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970712182103.Shimon>