Date: Thu, 23 Mar 2000 17:44:38 -0600 From: Dan Nelson <dnelson@emsphone.com> To: Greg Lehey <grog@lemis.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Alfred Perlstein <bright@wintelcom.net>, Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG Subject: Re: patches for test / review Message-ID: <20000323174438.B59166@dan.emsphone.com> In-Reply-To: <20000323152718.C9318@mojave.worldwide.lemis.com>; from "Greg Lehey" on Thu Mar 23 15:27:18 GMT 2000 References: <20000320115902.C14789@fw.wintelcom.net> <20211.953581241@critter.freebsd.dk> <20000320152330.A48212@dan.emsphone.com> <20000323152718.C9318@mojave.worldwide.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Mar 23), Greg Lehey said: > > Agreed. This is on the Vinum wishlist, but it comes at the expense of > reliability (how long do you wait to cluster? What happens if the > system fails in between?). In addition, for Vinum it needs to be done > before entering the hardware driver. For the simplest case, you can choose to optimize only when the user sends a single huge write(). That way you don't have to worry about caching dirty pages in vinum. This is basically what the hardware RAIDs I have do. They'll only do the write optimization (they call it "pipelining") if you actually send a single SCSI write request large enough to span all the disks. I don't know what would be required to get our kernel to even be able to write blocks this big (what's the upper limit on MAXPHYS)? -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000323174438.B59166>