From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 3 09:03:26 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 5190FFF6 for ; Sun, 3 Nov 2013 09:03:26 +0000 (UTC) (envelope-from symbolics@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DEA2524D3 for ; Sun, 3 Nov 2013 09:03:25 +0000 (UTC) Received: from lemon ([80.7.17.14]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MFuWk-1VO4Py0CfO-00EwjI for ; Sun, 03 Nov 2013 10:03:24 +0100 Received: by lemon (Postfix, from userid 1001) id 6A5ACEB2DA; Sun, 3 Nov 2013 09:03:23 +0000 (GMT) Date: Sun, 3 Nov 2013 09:03:23 +0000 From: symbolics@gmx.com To: Warren Block Subject: Re: GEOM mentor request Message-ID: <20131103090323.GA1744@lemon> References: <20131101103158.GA35397@lemon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K0:rW2soKbRotZJoiX6pFlXxnKqVoEsXj4i2ilDzNn6qSAf0doRPyC N97jcu4+CxTOeGBHCl/Mp+bnWZAFQfN3tKj+a5ipjrIqBxMAK6FXdc8ZYZs0u99tugkO/9w VnY8vxjZ5JIPWx6aK1xiheKbFloc3muRwYFERnAgj70rGxomumLn86xePa5KOcBam5gJERb +zdtF/7Iu2B7nHDgckTtA== 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 09:03:26 -0000 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. --sym