NetworkBlockDevice / nbd

Network Block Device
GNU General Public License v2.0
459 stars 120 forks source link

copy on write diff files are not getting removed #52

Closed zuwarm closed 7 years ago

zuwarm commented 7 years ago

Hi,

I built a network boot around Arch Linux using NBD. Several clients mount their root filesystem from the server, writes are going to diff file on the server. It works great, except the server isn't deleting the temporary diff files.

Here is what I use:

server cfg:

[generic] user = nbd group = nbd

[aclient] exportname = /opt/diskless/aclient.img copyonwrite = true cowdir = /tmp/

The export is a BTRFS formated sparse file.

I found a similar bug here: https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/696454 , but for me it is never working, even when I disconnect an export manually with 'nbdclient -d'

zuwarm commented 7 years ago

This is working now.

However it only deletes the file when I disconnect manually with nbd-client. My goal is a network boot. Apparently the clients are not explicitly disconnecting on shutdown. Isn't it possible to have the diff file deleted on TCP connection loss?

yoe commented 7 years ago

On Thu, Jul 13, 2017 at 06:30:43AM +0000, zuwarm wrote:

This is working now.

However it only deletes the file when I disconnect manually with nbd-client. My goal is a network boot. Apparently the clients are not explicitly disconnecting on shutdown. Isn't it possible to have the diff file deleted on TCP connection loss?

It should do that, but the timeout for the server may be longer than you expect. It is defined by the kernel, and is often something like two hours.

-- Could you people please use IRC like normal people?!?

-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab

zuwarm commented 7 years ago

You're right! The file is gone. I had to wait for 2 hours.

abligh commented 7 years ago

Presumably it would be relatively simple to add an option to tune tcp keepalive settings server side?

-- Alex Bligh

On 13 Jul 2017, at 13:26, zuwarm notifications@github.com wrote:

You're right! The file is gone. I had to wait for 2 hours.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

yoe commented 7 years ago

On Thu, Jul 13, 2017 at 09:14:30AM -0700, Alex Bligh wrote:

Presumably it would be relatively simple to add an option to tune tcp keepalive settings server side?

When I last checked, it wasn't; there was a global setting for all TCP connections on a given host, and you couldn't change that.

It is, of course, possible to have an application-layer "keepalive" message that the server could send unsolicited to the client and to which the client then needs to reply. However, the protocol assumes clients always send requests, and servers always send replies, so adding such a message to the NBD protocol will require some creativity.

-- Could you people please use IRC like normal people?!?

-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab

abligh commented 7 years ago

Let me check when I am back home. Pretty sure I wrote a JNI once that used an ioctl that worked on a single FD. If so will send a patch.

-- Alex Bligh

On 14 Jul 2017, at 21:38, Wouter Verhelst notifications@github.com wrote:

On Thu, Jul 13, 2017 at 09:14:30AM -0700, Alex Bligh wrote:

Presumably it would be relatively simple to add an option to tune tcp keepalive settings server side?

When I last checked, it wasn't; there was a global setting for all TCP connections on a given host, and you couldn't change that.

It is, of course, possible to have an application-layer "keepalive" message that the server could send unsolicited to the client and to which the client then needs to reply. However, the protocol assumes clients always send requests, and servers always send replies, so adding such a message to the NBD protocol will require some creativity.

-- Could you people please use IRC like normal people?!?

-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.