Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 3 Jan 2020 12:50:09 -0500
From:      Alexander Motin <mav@FreeBSD.org>
To:        Brooks Davis <brooks@freebsd.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r356108 - head/sys/geom/vinum
Message-ID:  <b1b4265f-3670-5025-c6af-4f2ab33b9f96@FreeBSD.org>
In-Reply-To: <20200103172634.GI91104@spindle.one-eyed-alien.net>
References:  <201912270136.xBR1aruf065831@repo.freebsd.org> <20200103172634.GI91104@spindle.one-eyed-alien.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 03.01.2020 12:26, Brooks Davis wrote:
> On Fri, Dec 27, 2019 at 01:36:53AM +0000, Alexander Motin wrote:
>> Author: mav
>> Date: Fri Dec 27 01:36:53 2019
>> New Revision: 356108
>> URL: https://svnweb.freebsd.org/changeset/base/356108
>>
>> Log:
>>   Reimplement gvinum orphanization.
>>   
>>   gvinum was the only GEOM class, using consumer nstart/nend fields. Making
>>   it do its own accounting for orphanization purposes allows in perspective
>>   to remove burden of that expensive for SMP accounting from GEOM.
>>   
>>   Also the previous implementation spinned in a tight event loop, waiting
>>   for all active BIOs to complete, while the new one knows exactly when it
>>   is possible to close the consumer.
> 
> Do you know if there are other cases of gvinum being a weird GEOM class?
> If it's going to require more rounds of major refactoring, maybe we
> should look into deprecating it for 14.

I've never used it myself, so may not know all of its issues.  From what
I briefly saw I have no other major objections about its code quality,
other than it probably being not very fast, considering it is
single-threaded and does not support unmapped I/O.  It does not support
resize, but not sure it is a big issue for its use case.  But mostly the
same, just a bit lighter, I can say about graid too, so gvinum does not
look particularly bad for me, other than unlike graid I don't have any
specific use case for it.

-- 
Alexander Motin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b1b4265f-3670-5025-c6af-4f2ab33b9f96>