"Justin Cormack wrote:"
> On Tue, 2003-03-25 at 17:27, Peter T. Breuer wrote:
> > > ENBD is not a replacement for NBD - the two are alternatives, aimed
> > > at different niches. ENBD is a sort of heavyweight industrial NBD. It
> > > does many more things and has a different achitecture. Kernel NBD is
> > > like a stripped down version of ENBD. Both should be in the kernel.
>
> hmm, I would argue that nbd is ok, as it is a nice lightweight block
> device (though I have not been able to use it due to the fact that I can
> never find a userspace and kernel that work together), while ENBD should
> be replaced by iscsi, now that is a real ietf standard, and can burn CDs
> across the net and all that extra stuff.
It's not a bad idea. But ENBD in particular can use any transport,
precisely becuase its networking is done in userspace. One only has to
write a stream.c module for it that implements
read
write
open
close
(There are currently implementations for three transports, including
tcp of course).
> And I am intending to write an iscsi client sometime, but it got
> delayed. The server stuff is already available from 3com.
Possibly, but ENBD is designed to fail :-). And networks fail.
What will your iscsi implementation do when somebody resets the
router? All those issues are handled by ENBD. ENBD breaks off and
reconnects automatically. It reacts right to removable media.
I should also have said that ENBD has the following features (I said I
forgot some!)
9) it drops into a mode where it md5sums both ends and skips writes
of equal blocks, if that's faster. It moves in and out of this mode
automatically. This helps RAID resyncs (2* overspeed is common on
100BT nets, that is 20MB/s.).
10) integration with RAID - it advises raid correctly of its state
and does hot add and remove correctly (well, you need my patches to
raid, but there you are ...).
Of course, if somebody wants me to make enbd appear like a scis device
instead of a generic block device, I guess I could do that. Except,
that yecch, I have seen the scsi code, and I do not understand it.
Another good idea is to make the wire protocol iscsi compatible. I
have no objection to that.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Mar 31 2003 - 22:00:21 EST