From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 3 15:32:06 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2C1C9236; Sun, 3 Nov 2013 15:32:06 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BE42B23D4; Sun, 3 Nov 2013 15:32:05 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id rA3FW4Sd038854; Sun, 3 Nov 2013 08:32:04 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id rA3FW3sB038851; Sun, 3 Nov 2013 08:32:04 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sun, 3 Nov 2013 08:32:03 -0700 (MST) From: Warren Block To: symbolics@gmx.com Subject: Re: GEOM mentor request In-Reply-To: <20131103090323.GA1744@lemon> Message-ID: References: <20131101103158.GA35397@lemon> <20131103090323.GA1744@lemon> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 03 Nov 2013 08:32:04 -0700 (MST) Cc: geom@freebsd.org, hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 15:32:06 -0000 On Sun, 3 Nov 2013, symbolics@gmx.com wrote: > On Fri, Nov 01, 2013 at 01:23:12PM -0600, Warren Block wrote: >> On Fri, 1 Nov 2013, symbolics@gmx.com wrote: >> >>> + Implement new things. Some ideas I have had: >>> + GEOM "ERASE" - Rewrite deletes into random writes. >>> + GEOM "PLUG" - Persistent version of the connect/disconnect verbs >>> where the flag sits in the class metadata. This might be a cleaner >>> approach, rather than adding the verbs to all the existing >>> providers. >>> + GEOM "TAP" - Allow userspace processes to hook into the GEOM >>> API. Intended for debugging and development. >>> + GEOM "WCACHE" - Allow you to use small, fast provider as a buffer >>> for a larger, slower provider. >>> + GEOM DTrace provider. Provide GEOM specific probes to complement >>> the IO provider. >>> + Probably other bits I can't remember right now. >> >> How about an explicit geom retaste command? "true > /dev/ada0" is >> misleading to the reader. > > Yes, that would be good. It's on my list. > >> Also, a RAM-cached version of gmirror that would report writes finished >> as soon as the faster drive finishes. Kind of the opposite of the >> WCACHE above. This would permit creating mirrors of an SSD and hard >> drive without performance loss, at least up until available write >> buffer space runs out. This one may not be so easy. > > I can see the benefit. This would be like a mirror with a journal. As > long as it has a different name from mirror, 'lazy mirror' ?, I think it > would be interesting. The only concern I have would be that some users > could use it and assume the normal mirror semantics, e.g. that all discs > are equally redundant, which wouldn't be true. I've been calling it a "slow" mirror. Come to think of it, that's a little misleading. "Async mirror"? There may be an existing term. As pointed out, it's probably non-trivial to implement. The WCACHE you suggest above (the Linux guys have "bcache") is probably more benefit to more people.