[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFR] templates://nbd/{nbd-client.templates,nbd-server.templates}



On Wed, Apr 29, 2009 at 10:17:58PM +0100, Justin B Rye wrote:
> >  Template: nbd-client/killall
> [...]
> >  _Description: Kill all nbd devices on 'stop'?
> 
> "Killing" a device suggests smashing the hardware; as far as I can
> see there's not even any use of kill or killall here, just umount.

There's a disconnect too, actually.

Perhaps 'kill' might be too strong, but 'umount' definitely does not
cover everything. The only reason this question exists is because
disconnecting an nbd device, contrary to umounting a file system, is
perfectly possible _even if the device is in use_. Doing this when not
intended *will* cause data loss, so we have to be rather careful.

> Also, s/nbd/NBD/.
> 
> >   When the nbd-client initscript is called to stop the nbd-client
> >   service, there are two things that can be done: either it can stop all
> >   nbd-client devices, or it can stop only those nbd-client devices that
> >   it knows about in its config file.
> 
> That's okay, but I don't like the next paragraph:
> 
> >   The traditional behaviour was to stop all nbd-client devices, including
> >   those that were not specified in the nbd-client config file; for that
> >   reason, the default answer is to kill all nbd devices. However, if you
> > + are running critical file systems, such as the root device, on NBD,
> >   then this is a bad idea; in that case, please do not accept this
> >   option.
> 
> s/behaviour/behavior/; but why the past tense if it's still the
> default?  And reduce the repetition:

The traditional behaviour was not configurable; it would *always*
disconnect all devices. I received a (valid, of course) bug report about
that, which is why this feature was added.

[...]
-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


Reply to: