Hi Evgeniy,
Nit alert:
On Tuesday 31 July 2007 10:13, Evgeniy Polyakov wrote:
> * storage can be formed on top of remote nodes and be exported
> simultaneously (iSCSI is peer-to-peer only, NBD requires device
> mapper and is synchronous)
In fact, NBD has nothing to do with device mapper. I use it as a
physical target underneath ddraid (a device mapper plugin) just like I
would use your DST if it proves out.
Regards,
Daniel
Hi Daniel.
> On Tuesday 31 July 2007 10:13, Evgeniy Polyakov wrote:
> > * storage can be formed on top of remote nodes and be exported
> > simultaneously (iSCSI is peer-to-peer only, NBD requires device
> > mapper and is synchronous)
>
> In fact, NBD has nothing to do with device mapper. I use it as a
> physical target underneath ddraid (a device mapper plugin) just like I
> would use your DST if it proves out.
I meant to create a storage on top of several nodes one needs to have
device mapper or something like that on top of NBD itself. To further
export resulted device one needs another userspace NDB application and
so on. DST simplifies that greatly.
DST original code worked as device mapper plugin too, but its two
additional allocations (io and clone) per block request ended up for me
as a show stopper.
--
Evgeniy Polyakov
On Saturday 04 August 2007 09:44, Evgeniy Polyakov wrote:
> > On Tuesday 31 July 2007 10:13, Evgeniy Polyakov wrote:
> > > * storage can be formed on top of remote nodes and be
> > > exported simultaneously (iSCSI is peer-to-peer only, NBD requires
> > > device mapper and is synchronous)
> >
> > In fact, NBD has nothing to do with device mapper. I use it as a
> > physical target underneath ddraid (a device mapper plugin) just
> > like I would use your DST if it proves out.
>
> I meant to create a storage on top of several nodes one needs to have
> device mapper or something like that on top of NBD itself. To further
> export resulted device one needs another userspace NDB application
> and so on. DST simplifies that greatly.
>
> DST original code worked as device mapper plugin too, but its two
> additional allocations (io and clone) per block request ended up for
> me as a show stopper.
Ah, sorry, I misread. A show stopper in terms of efficiency, or in
terms of deadlock?
Regards,
Daniel
On Sun, Aug 05, 2007 at 01:06:58AM -0700, Daniel Phillips ([email protected]) wrote:
> > DST original code worked as device mapper plugin too, but its two
> > additional allocations (io and clone) per block request ended up for
> > me as a show stopper.
>
> Ah, sorry, I misread. A show stopper in terms of efficiency, or in
> terms of deadlock?
At least as in terms of efficiency. Device mapper lives in happy world
where memory does not end and allocations are fast.
--
Evgeniy Polyakov
On Sunday 05 August 2007 08:01, Evgeniy Polyakov wrote:
> On Sun, Aug 05, 2007 at 01:06:58AM -0700, Daniel Phillips wrote:
> > > DST original code worked as device mapper plugin too, but its two
> > > additional allocations (io and clone) per block request ended up
> > > for me as a show stopper.
> >
> > Ah, sorry, I misread. A show stopper in terms of efficiency, or in
> > terms of deadlock?
>
> At least as in terms of efficiency. Device mapper lives in happy
> world where memory does not end and allocations are fast.
Are you saying that things are different for a network block device
because it needs to do GFP_ATOMIC allocations? If so then that is just
a misunderstanding. The global page reserve Peter and I use is
available in interrupt context just like GFP_ATOMIC.
Regards,
Daniel
On Sun, Aug 05, 2007 at 02:35:04PM -0700, Daniel Phillips ([email protected]) wrote:
> On Sunday 05 August 2007 08:01, Evgeniy Polyakov wrote:
> > On Sun, Aug 05, 2007 at 01:06:58AM -0700, Daniel Phillips wrote:
> > > > DST original code worked as device mapper plugin too, but its two
> > > > additional allocations (io and clone) per block request ended up
> > > > for me as a show stopper.
> > >
> > > Ah, sorry, I misread. A show stopper in terms of efficiency, or in
> > > terms of deadlock?
> >
> > At least as in terms of efficiency. Device mapper lives in happy
> > world where memory does not end and allocations are fast.
>
> Are you saying that things are different for a network block device
> because it needs to do GFP_ATOMIC allocations? If so then that is just
> a misunderstanding. The global page reserve Peter and I use is
> available in interrupt context just like GFP_ATOMIC.
No, neither device needs atomic allocations, I just said that device
mapper is too expensive, since it performs alot of additional
allocations in the fast path and is not designed to cases when
allocation fails, since there is no recovery path and (maybe because of
this) mempool allocation waits forever until there is free memory
and can not fail.
--
Evgeniy Polyakov