Re: [Nbd] nbd for large scale diskless linux

[Wouter Verhelst <wouter@...3...>]

On Sun, Oct 09, 2005 at 11:10:46AM +0200, dsuchod wrote:
> Hi!
> > > Unfortunately SuSE does not provide a nbd package, so didn't try it
> > > from a SuSE server system (same architecture, 2.6.11 amd64 kernerl)
> > > yet ... but that could be done in some next steps ...
> > 
> > The server's kernel isn't all that important, really. Nbd-server does
> > use <linux/nbd.h>, but that's only to get some constants it needs for
> > the protocol -- if you copy that one file, you can theoretically build
> > it on every POSIX compliant system (and I'm sure it has been built
> > successfully on at least The Hurd and on FreeBSD, since I've tried it on
> > those myself)
> 
> I build the binaries without problems on the SuSE system. I have checked: 
> With the next SuSE10.0 release the nbd package is part of it (not the
> opensuse, but within the boxed version) ...
> 
> > > I was using the 2.7.3 client tools from the sourceforge repository and:
> > > 
> > > lp-srv02a:~# nbd-server --help
> > > This is nbd-server version 2.7.3
> 
> Is 2.7.4 on the next SuSE then.

Interesting...

> > cowloop? Is that a specific kernel feature?
> 
> Yes it is another kernel package, but not in the mainstream kernel yet. It 
> is an block level alternative to unionfs (which is not stable enough to 
> use in production environment - at least the diskless clients).
>  
> > If it's the copy-on-write option in nbd you're talking about then please
> > don't do it. It's ugly and dogslow, I should've kicked it out ages ago.
> 
> I read that on the enbd pages. They talk on that feature somewhere. But I 
> do not know how they do that (file in ramdisk or writeable space somewhere
> or directly to ram) ... I post a message to their list too ... It would 
> reduce complexity in my filesystem setup.

I don't know how ENBD does it; but NBD uses a (very ugly) array in
memory to map blocks in the exported file to blocks in the copy-on-write
file, and the copy-on-write file just gets new blocks appended at the
end; this makes sequential access horribly slow.

I've been thinking of using sparse files to implement this
faster/better. See http://nbd.sourceforge.net/roadmap.html for details.
Until that's happened, though, you shouldn't use the copy-on-write
feature.

> > > > There've even been people using RAID1 root devices over NBD. There's a
> > > > link to that on the NBD home page.
> 
> Their client seems to have a multiple connection (port) feature. Their 
> examples just go onto one single server, but I'm curious if I could point 
> it for two different servers who sync a common partition via network
> blockdevice raid1.
> 
> Have a nice sunday! Dirk
> 

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond