Date: Sun, 22 Mar 2009 10:51:29 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: luigi@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>, Ivan Voras <ivoras@freebsd.org>, freebsd-geom@freebsd.org Subject: Re: disk scheduling (was: Re: RFC: adding 'proxy' nodes to provider ports (with patch)) Message-ID: <eb21ef440903220251m67700679r7fe6662f9081e910@mail.gmail.com> In-Reply-To: <45710.1237709582@critter.freebsd.dk> References: <eb21ef440903211800h266ec0aes158cb189095289c1@mail.gmail.com> <45710.1237709582@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 22, 2009 at 9:13 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> In message <eb21ef440903211800h266ec0aes158cb189095289c1@mail.gmail.com>, Luigi
> Rizzo writes:
>
>>The thread was meant to be on inserting transparent nodes in GEOM.
>>
>>Scheduling was just an example on where the problem came out,
>
> Scheduling is the *only* application I have seen mentioned for
> this special case geom construct ?
man 4 geom has a section which explicitly mentions this construct,
with the same example that you posted in the thread:
...
SPECIAL TOPOLOGICAL MANEUVERS
INSERT/DELETE are very special operations which allow a new geom to be
instantiated between a consumer and a provider attached to each other and
to remove it again.
To understand the utility of this, imagine a provider being mounted as a
file system. Between the DEVFS geom's consumer and its provider we
insert a mirror module which configures itself with one mirror copy and
consequently is transparent to the I/O requests on the path. We can now
configure yet a mirror copy on the mirror geom, request a synchroniza-
tion, and finally drop the first mirror copy. We have now, in essence,
moved a mounted file system from one disk to another while it was being
used. At this point the mirror geom can be deleted from the path again;
it has served its purpose.
>>+ changing disksort can do some things but not all one would want.
>> [...]
>
> Then the correct answer is to insert a perfectly normal geom
> class above the disk drive to implement that. I totally fail
> to se what special kind of classes would buy you ?
>
>>if you want a quick example [...]
>
> I know what anticipatory disk-scheduling is, what it does,
> and what the downsides of it are. (I also know that with
> SSD's it becomes all but pointless).
>
> The question is not if we should improve disksorting, the question
> is if we need to hack up GEOM for it.
>
> The answer is "no".
Ok good, we are back on track on the geom architecture:
then the question was just whether the INSERT/DELETE mentioned in
the manpage was already supported or not, and how to implement
it in a clean way.
Hopefully the discussion in the main thread now contains enough
detail to do it the right way.
cheers
luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?eb21ef440903220251m67700679r7fe6662f9081e910>