On Sat, Apr 09, 2005 at 05:19:43PM -0400, David Gilbert wrote: +> I have two systems, each with 4 300 gig SATA disks. Let's call them +> m0 and m1. M1 exports it's disks with ggated ... on two private GigE +> networks. M0, on those same two GigE networks, imports them with +> ggatec. M0, then does the following: +> +> Mirror Disks +> ====== ===== +> s0 ggate0 da0s1g +> s1 ggate1 da1s1g +> s2 ggate2 da2s1g +> s3 ggate3 da3s1g +> +> And then: +> +> concat Disks +> ====== ===== +> v0 s0 s1 s2 s3 +> +> (so v0 is a concatination of 4 mirrors that consist of a local and +> remote disk, each) +> +> Now... This all works, and we create a filesystem on v0. The problem +> arises that whenever a lot of activity occurs on v0 (untaring a copy +> of /usr is sufficient), the ggate links break down. An example +> message from the dmesg: +> +> GEOM_MIRROR: Request failed (error=5). ggate2[WRITE(offset=259891840000, length=8192)] +> +> Now... I don't know a lot about ggate, but this appears trivial to +> trigger. Has anyone tried similar configurations and is there any +> wisdom about ggate configurations?
Set kern.geom.gate.debug to 1 and send output which is generated on failures. I've much improved ggate in perforce, but it needs some polishing still... -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am!
pgpSqGJL3Gspx.pgp
Description: PGP signature
