bkbits.net downtime
Our T1 supplier, Global Crossing, is repairing a router at midnight Saturday PST. Expected downtime is 3 hours but you never know. If it turns out that they screw things up, we'll physically move bkbits.net to a different location Sunday or Monday.
Sync those trees...
Quoted 4 lines · Larry McVoy
Our T1 supplier, Global Crossing, is repairing a router at midnight Saturday PST. Expected downtime is 3 hours but you never know. If it turns out that they screw things up, we'll physically move bkbits.net to a different location Sunday or Monday.
Actually, with BK it should be possible to have read only clones on multiple servers, should it not? Not that I'm saying BK should foot the bill to do that, but having read-only clones of the primary kernel trees would avoid most downtime.
I suppose it would be difficult for two servers to do a merge with conflicts by themselves so multiple write clones are probably not super desirable, but read-only clones should be pretty easy to set up and keep up-to-date via "bk pull" (or even "bk push" triggered by a commit script).
You could allow writing on a single read-only clone while the primary is down and then update the primary when you move back, if that was an issue, although I'm guessing that the DNS updates would take longer to propagate than most outages.
I wonder if any of the kernel.org mirror sites would be interested in hosting a clone of one or more BK repositories.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Quoted 4 lines · Andreas Dilger
Actually, with BK it should be possible to have read only clones on multiple servers, should it not? Not that I'm saying BK should foot the bill to do that, but having read-only clones of the primary kernel trees would avoid most downtime.
At the risk of suggesting something insanely complex...
... assuming BK read-only copies do work, why not actually have 'bk pull' for hosts which can serve RO copies of the trees? You could use SRV records to locate these transparently to what has been deployed now (I'm not really a fan of rfc2782.txt but nonetheless it exists and others are using it, so it's a 'standard' of sorts).
Presumably doing something like this means you could have many people voluntarily providing RO trees for different projects and lessen the load on the bitmover infrastructure...
--cw
Quoted 5 lines · Chris Wedgwood
... assuming BK read-only copies do work, why not actually have 'bk pull' for hosts which can serve RO copies of the trees? You could use SRV records to locate these transparently to what has been deployed now (I'm not really a fan of rfc2782.txt but nonetheless it exists and others are using it, so it's a 'standard' of sorts).
Or simply a domain-name with multiple A's with should work today out-of-the-box.
Signature · 1 line
Anders Gustafsson - [email protected] - http://0x63.nu/
Quoted 2 lines · Anders Gustafsson
Or simply a domain-name with multiple A's with should work today out-of-the-box.
How do you differentiate RO from RW hosts then?
--cw
Quoted 4 lines · Chris Wedgwood
Quoted 2 lines
Or simply a domain-name with multiple A's with should work today out-of-the-box.
How do you differentiate RO from RW hosts then?
You don't :)
Except by giving the write-host a different name.
Signature · 1 line
Anders Gustafsson - [email protected] - http://0x63.nu/
Quoted 14 lines · Chris Wedgwood
Quoted 4 lines · Andreas Dilger
Actually, with BK it should be possible to have read only clones on multiple servers, should it not? Not that I'm saying BK should foot the bill to do that, but having read-only clones of the primary kernel trees would avoid most downtime.
At the risk of suggesting something insanely complex...
... assuming BK read-only copies do work, why not actually have 'bk pull' for hosts which can serve RO copies of the trees? You could use SRV records to locate these transparently to what has been deployed now (I'm not really a fan of rfc2782.txt but nonetheless it exists and others are using it, so it's a 'standard' of sorts).
Quoted 3 lines
Presumably doing something like this means you could have many people voluntarily providing RO trees for different projects and lessen the load on the bitmover infrastructure...
That's exactly what I was suggesting, but not very clearly it seems.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Quoted 2 lines
Actually, with BK it should be possible to have read only clones on multiple servers, should it not?
Oh, sure. Even if we were down for a week, the trees which people care about are almost certainly on their local disks so they could set up servers all over the place make the data available if need be.
bkbits.net is a cache, it's not the authoritative source of anything.
Quoted 2 lines
I wonder if any of the kernel.org mirror sites would be interested in hosting a clone of one or more BK repositories.
Eventually we'll have a version of the BKD that we've bullet proofed enough that we'd encourage that. For the time being we've encouraged hosting at bkbits.net simply because (a) the infrastructure is there and (b) if there are security problems then it's our mess not yours.
It's partially self interest: if kernel.org got compromised and it was our fault then we'd get a black eye. If bkbits got compromised we'd just fix it up quietly (and, no, so far it has never been broken into but that's probably because we're very careful about how we run things, even if you got in via BKD you'd have no write permissions on anything but tmp dirs).
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm