Re: [Nbd] (no subject) sync/cache/flush of devices
- To: Daniel Schwager <Daniel.Schwager@...207...>
- Cc: nbd-general@lists.sourceforge.net
- Subject: Re: [Nbd] (no subject) sync/cache/flush of devices
- From: Wouter Verhelst <w@...112...>
- Date: Wed, 15 Jul 2009 12:57:42 +0200
- Message-id: <20090715105742.GJ1848@...510...>
- In-reply-to: <EB31672367A401439CD5A4A10889D57B019891D0@...661...>
- References: <EB31672367A401439CD5A4A10889D57B019891C8@...661...> <4A5CC30E.50101@...124...> <EB31672367A401439CD5A4A10889D57B019891CD@...661...> <4A5CCB55.1030004@...124...> <EB31672367A401439CD5A4A10889D57B019891D0@...661...>
On Tue, Jul 14, 2009 at 08:36:20PM +0200, Daniel Schwager wrote:
> > - Is there a possibility to sync ONLY my device on client side ?
> > Yes, fsync the file descriptor you have opened on the file or device.
>
> Ok - will try it.
>
> Featurerequest: The normal szenario using nbd is over a network -
> therefore
> a disconnect of the client should fsync the disk before disconnecting
> (this
> can be done inside nbd-client).
>
> What's you opinion ?
I guess it would make sense to have the client make sure that all
outstanding requests are sent off before closing the connection.
> > > And KILL the nbd-server after ?
> >
> > The client disconnect will cause the server to die. If either end of
> > the connection is terminated, the other side will also stop.
>
> NACK - i tried this on a nbd-server running @opensolaris - after
> disconnect the nbd-client@...662..., the nbd-server still runs on solaris.
> It was not stopped.
It should, really. If it doesn't, and the disconnect was done properly
(i.e., by using nbd-client -d), then that's a bug. Note that even if it
doesn't, the server has the TCP_KEEPALIVE socket option set, so it
should still die after about two hours and ten minutes (note that this
time is implementation-specific, but on Linux such is the default).
> I have to kill it (but is there a cache inside nbd-server - if so,
> killing destroy also my cached data ...)
No, there is no cache in nbd-server. It is pretty dumb in that regard;
all requests are handled immediately. For any caching or optimization,
it relies on the client and/or kernel it's running on.
--
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: