Re: [RFD] Layering: Use-Case Composers (was: DRBD - what is it, anyways? [compare with e.g. NBD + MD raid])

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 13 Aug 2007, David Greaves wrote:

[email protected] wrote:
 per the message below MD (or DM) would need to be modified to work
 reasonably well with one of the disk components being over an unreliable
 link (like a network link)

 are the MD/DM maintainers interested in extending their code in this
 direction? or would they prefer to keep it simpler by being able to
 continue to assume that the raid components are connected over a highly
 reliable connection?

 if they are interested in adding (and maintaining) this functionality then
 there is a real possibility that NBD+MD/DM could eliminate the need for
 DRDB. however if they are not interested in adding all the code to deal
 with the network type issues, then the argument that DRDB should not be
 merged becouse you can do the same thing with MD/DM + NBD is invalid and
 can be dropped/ignored

 David Lang

As a user I'd like to see md/nbd be extended to cope with unreliable links.
I think md could be better in handling link exceptions. My unreliable memory recalls sporadic issues with hot-plug leaving md hanging and certain lower level errors (or even very high latency) causing unsatisfactory behaviour in what is supposed to be a fault 'tolerant' subsystem.


Would this just be relevant to network devices or would it improve support for jostled usb and sata hot-plugging I wonder?

good question, I suspect that some of the error handling would be similar (for devices that are unreachable not haning the system for example), but a lot of the rest would be different (do you really want to try to auto-resync to a drive that you _think_ just reappeared, what if it's a different drive? how can you be sure?) the error rate of a network is gong to be significantly higher then for USB or SATA drives (although I suppose iscsi would be limilar)

David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux