Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 3 Nov 2013 08:32:03 -0700 (MST)
From:      Warren Block <wblock@wonkity.com>
To:        symbolics@gmx.com
Cc:        geom@freebsd.org, hackers@freebsd.org
Subject:   Re: GEOM mentor request
Message-ID:  <alpine.BSF.2.00.1311030801540.38648@wonkity.com>
In-Reply-To: <20131103090323.GA1744@lemon>
References:  <20131101103158.GA35397@lemon> <alpine.BSF.2.00.1311011310340.23437@wonkity.com> <20131103090323.GA1744@lemon>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1311030801540.38648>