[OpenIndiana-discuss] Standard flag for fast shutdown

[James Carlson]

On 02/18/14 10:11, Jim Klimov wrote:
> If the system is not time-constrained about the shutdown, it might
> (like some DBMS/LDAP servers do) stop accepting new requests, go
> on timely finishing the old requests, and when none are left in
> the backlog - finally turn off. Hopefully the requests are at this
> time handled by other replicas of the service.

Perhaps it's just me, but I think that's really an application issue,
not a system issue.  I'd send SIGPWR to all processes, then later send
SIGTERM to catch the stragglers who don't know SIGPWR, wait as long as
practical, and then kick the machine over in a controlled way.  Kicking
it over using "uadmin" is a bit more controlled than allowing the UPS to
cut out -- uadmin will give the file systems a chance to sync.

> Similarly for fileservers backing VMs in my other example.
> One thing is a consistent disk image, and another is a VM
> needing or not needing fsck or other data recovery inside
> that image. And yet another - is the lengthiness of a full
> VM shutdown vs. VM going to sleep and saving-state on disk.

That sounds like the VM designer's problem to me.  The designer has to
map simulated synchronous writes from the client into something like
actual synchronous writes so that the client gets the same semantics
with respect to non-volatile storage.  Otherwise, a power loss or crash
without warning (which can *always* happen, no matter what precautions
you take) can result in inconsistent data.

>>>    And on a similar note, are there any tricks for an OI NFS
>>> server to report to its clients that it is going to shut down?
>>> Usecase might be similar - a rebooting/UPS-shutdowning NFS
>>> server hosting some VM images can nicely tell its clients
>>> (VM hosts) to savestate and wait for it to come back...
>>
>> A properly designed NFS client is always able to handle an NFS server
>> going away without notice.  If it's not properly designed, then no
>> extension or "trick" is likely to make it work.
> 
> This is good as long as some servers and the clients stay up
> and cache the in-flight data to be saved onto storage later.
> At the moment I have to think about the scenario when they
> are all going down - how to ensure the least losses possible :)

I'm not aware of any such problem with NFS.  When the NFS server acks
the data, and the client has asked for stable storage, the data have
been committed.  If the server crashes before the commit, no ack occurs,
and the client knows that the write might have been lost.  See RFC 3530
section 14.2.36.  Clients get what they ask for.

Obviously, when the system goes down, the contents of ordinary DRAM are
lost.  But so what?  If the applications are designed with consistency
in mind, then they'll do what's necessary to recover.  That's why
databases have transaction logs and network protocols have retry mechanisms.

If they're not designed to handle this problem, there's only so much you
can do.  As long as the abrupt failure case still exists (and there's no
practical means to prevent it), it seems a little odd to me to polish
this failure mode to a high gloss.

-- 
James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>