On 2016-01-09 14:05, Christoph Biedl wrote:
Austin S. Hemmelgarn wrote...
(...) If you only ever
need to access the device locally on the network served by the router
however, I'd actually suggest ATAoE over iSCSI or NBD, it's a lot more
efficient and technically more secure because it's non-routable (it runs
directly over the link layer, which means you avoid the overhead of IP and
TCP, and has the added advantage that you technically don't need anything
but the kernel driver on the client side).
Although pretty offtopic ... AoE is not routable but don't sell this
as a security feature. If you cannot configure ACLs, you're doomed
anyway. The only security model AoE provides is the client's MAC
address but spoofing is really not a problem.
I should have qualified this, I meant it's more secure against
accidental leaks off network. I've had issues with this in the past
with iSCSI where the initiator got confused and tried to contact
something across the internet. In addition to that, NBD and iSCSI still
are no more secure against data loss if your network is actually
compromised (because of how most home routers are configured (and in may
cases, are forced to be configured), it's trivial to read all the
traffic on the network if the router is compromised, and only slightly
more difficult if you get admin access on a system on the network), they
just provide better protection against DoS attacks.
So in short:
* AoE is really simple to set up but if there's even a remote chance
some evil guy is in your network (i.e. ethernet broadcast domain),
just forget it. Also AoE completely relies on the ethernet checksums
to detect data curruption, and I had some funny experiences because
of that.
Except that if you run BTRFS on it too, that provides further
protection. And, if you've got properly working hardware, this degree
of data protection should be perfectly fine (if you're getting Ethernet
frames with bad checksums that get through on the recipient, then
something is wrong with your network).
* NBD has (or had the last time I checked some 15 months ago) some
serious issues on client side if the server becomes unavailable,
including data loss. Yes, I should debug this one day.
It still has issues, but I don't think they're as bad as they used to
be. The only cases I would advocate it's usage for is exposing stuff
temporarily to VM's that don't allow run-time reconfiguration of block
storage, and using qemu-nbd to expose disk images to a system as block
devices.
* iSCSI probably provides everything you want. At the price of having
to understand how to set it up. I failed several times and
eventually gave up, your mileage may vary.
And the price of efficiency. iSCSI is over-engineered for
non-enterprise usage, and largely impractical for people who have no
experience with it (as you found out several times).
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
