From: Sean Reifschneider <jafo@tummy.com>
To: linux-kernel@vger.kernel.org
Cc: torvalds@transmeta.com
Subject: Re: eNBD on loopback [was Re: [PATCH] 2.5.8 IDE 36]
Date: Sat, 20 Apr 2002 21:28:33 -0600 [thread overview]
Message-ID: <20020420212833.G2866@tummy.com> (raw)
>Don't ask me, I'm not a user, I have just seen the patch submissions, and
>I just want to get real user feedback before I'd merge a new "extended
>nbd".
I haven't used enbd, because the site was down the weekend I was evaluating
the alternatives... I did try NBD and DRBD, however. My experience was
that enbd could hardly be worse than nbd, for the following reasons:
The nbd server software referenced in the Configuration documentation
(the only I was able to find, and that only after some digging), would
fail rather quickly because the remote kernel would send a request much
larger than the server was expecting.
After a couple of days, the primary machine would just lock up when
running RAID-1 on top of the NBD.
The NBD server code is, not pretty... It sounds like that server was
written as just a hack, and really hasn't been looked at since then.
This was with kernel version 2.4.18.
DRBD is what I'm currently using and it's been running for a few weeks now
without any problems. It combines the mirroring and NBD functionality into
a single combined package. A nice feature of DRBD is that it understands
about the second node and can do things like wait for a RAID mirror to
finish before starting up other processes.
enbd has some nice features, particularly it looks like the server code
has had a lot more development in it. Particularly nice is that the
client/server will auto-negotiate an optimized mirror mode where they will
exchange MD5 sums of each block, and only transmit the block if the MD5 is
different... It switches to and from this mode automatically.
I can't really on wether enbd should be in the kernel... It can't be worse
than nbd, based on my experience. It's active development makes it a
better choice to include.
Sean
--
Fire at the celuloud factory. No film at eleven.
-- _Kentucky_Fried_Movie_
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
next reply other threads:[~2002-04-21 3:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-21 3:28 Sean Reifschneider [this message]
2002-04-21 10:40 ` eNBD on loopback [was Re: [PATCH] 2.5.8 IDE 36] Anton Altaparmakov
2002-04-21 11:41 ` Sean Reifschneider
2002-04-22 0:17 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2002-04-16 16:05 [PATCH] 2.5.8 IDE 36 Alan Cox
2002-04-16 15:56 ` Linus Torvalds
2002-04-18 20:33 ` eNBD on loopback [was Re: [PATCH] 2.5.8 IDE 36] Pavel Machek
2002-04-18 20:39 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020420212833.G2866@tummy.com \
--to=jafo@tummy.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox