From owner-freebsd-geom@FreeBSD.ORG Sat Feb 21 07:45:43 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 777A916A4CE; Sat, 21 Feb 2004 07:45:43 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id E051443D1D; Sat, 21 Feb 2004 07:45:42 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.10/8.12.10) with ESMTP id i1LFjcbq062346; Sat, 21 Feb 2004 16:45:38 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: Lukas Ertl From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 21 Feb 2004 16:40:56 +0100." <20040221162942.P19540@leelou.in.tern> Date: Sat, 21 Feb 2004 16:45:38 +0100 Message-ID: <62345.1077378338@critter.freebsd.dk> cc: geom@freebsd.org Subject: Re: GEOM + RAID5 help X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2004 15:45:43 -0000 In message <20040221162942.P19540@leelou.in.tern>, Lukas Ertl writes: >Hi, > >I'm currently implementing the RAID5 bit of geom_vinum, and I could use a >little help. One problem I'm faced is that if the subdisk where the >original request should go to is down, I need to read all the other >stripes, recalculate the parity with the original data, and then write the >parity stripe (in the BIO_WRITE case), or read all other stripes plus the >parity to recalculate the desired data (in the BIO_READ case). > >If I'm not mistaken then I'm not allowed to use g_read_data in the IO >path, so how can I correctly get at the data of the other stripes? Should >I create my own bio (how?) with the appropriate bio_cmd and send it down >the path using g_io_request (where should I issue it? In my bio_done >routine?)? Go look at sys/geom/bde/g_bde_work.c, it does something very similar. Basically, you need to implement a state engine. You do not need to have a thread for it like GBDE, because the XOR is a lot cheaper than a full crypto. So what you do is you allocate the necessary number of bio structures fill them in and ship them down. The biodone routine you specify should then update status, and when all bits have arrived, do the XOR and complete the operation. Read the bit in sys/geom/notes about locking of bio_children carefully as it will save you a lot of locking worries. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.