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/