On Mon, Aug 30, 2010 at 1:14 PM, K. Richard Pixley <rich@xxxxxxxx> wrote: > In terms of fault tolerance, I'd call this a tolerance of about a half a > fault since the system cannot return to it's initial configuration without > breaking continuity of service. > > And there really isn't any way to extend this. It's not fault tolerance in > the virtual synchrony sense where there can be a pool of N machines, all > symmetric, which can tolerate N - 1 failures and produce continuing service > throughout. > > It's also not load balanced in the virtual synchrony sense where N machines > can all be in service concurrently and the service can tolerate N - 1 > failures, albeit at degraded performance. Or in the sense where failed > servers can return to the group dynamically. > > It's not sufficient for any application in which I've ever sought fault > tolerance. If it's sufficient for you, that's great. But my definition of > "fault tolerance" requires that the system be capable of returning to it's > initial state without loss of service. The heartbeat approach with single > failover can't do that. > > --rich - who is likely now off topic. Only off-topic if BTRFS isn't ever going to ooze into the space currently occupied by the likes of http://en.wikipedia.org/wiki/Global_File_System that is, file systems that have multiple nodes simultaneously accessing block devices and tolerating faults. There's more to HA than the file system though; well, depending on what kinds of faults you're worried about mitigating the risk of. I imagine (very likely now pollyanna) that refactoring GFS's lock discipline to work above BTRFS's on-disk format might be a worthwhile endeavour, or at least something to think about. Reimplementing the locking over BTRFS might be a shorter way there. I'm for modular extent provisioning, which in theory could allow all kinds of unnecessarily wasted CPU cycles, as extents get managed by user-space daemons allocating them out of whatever file systems they happen to be running on. -- "Elevator Inspection Certificate is on file in the Maintenance Office" -- 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
