FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 03-01-2011, 12:46 PM
Alasdair G Kergon
 
Default Huge memory allocation

On Tue, Mar 01, 2011 at 03:04:56PM +0200, Eli Malul wrote:
> dm_malloc_aux do not allow memory allocation greater than 50000000.

That was to catch software bugs: it was a number bigger than ever
needed. Change it if you need to, but I need stronger evidence
of the need for your particular way of doing things before
I'll change it in the upstream tree!

Alasdair

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-03-2011, 07:05 AM
"Eli Malul"
 
Default Huge memory allocation

I am expecting to have lots of (up to million) scattered extents across
some volumes which I am required to mirror.
Since mirror mapped device with a table that large consume unbearable
amount of memory (e.g. for 10,000 extents I saw about 6 Giga of memory
allocated by the device-mapper) I am going to create two linear devices
which maps these extents and mirror them.

In addition, I am required to preserve the original extent's offsets
since they are an existing user data used by DB applications.
To achieve that I will create another linear device to simulate the
original extent's offsets which shall be mapped to the created mirrored
device so, the client will continue to read and write the same offsets.

-----Original Message-----
From: Alasdair G Kergon [mailto:agk@redhat.com]
Sent: Tuesday, March 01, 2011 3:46 PM
To: Eli Malul
Cc: dm-devel@redhat.com
Subject: Re: [dm-devel] Huge memory allocation

On Tue, Mar 01, 2011 at 03:04:56PM +0200, Eli Malul wrote:
> dm_malloc_aux do not allow memory allocation greater than 50000000.

That was to catch software bugs: it was a number bigger than ever
needed. Change it if you need to, but I need stronger evidence
of the need for your particular way of doing things before
I'll change it in the upstream tree!

Alasdair


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-03-2011, 07:41 AM
Zdenek Kabelac
 
Default Huge memory allocation

Dne 3.3.2011 09:05, Eli Malul napsal(a):
> I am expecting to have lots of (up to million) scattered extents across
> some volumes which I am required to mirror.
> Since mirror mapped device with a table that large consume unbearable
> amount of memory (e.g. for 10,000 extents I saw about 6 Giga of memory
> allocated by the device-mapper) I am going to create two linear devices
> which maps these extents and mirror them.
>
> In addition, I am required to preserve the original extent's offsets
> since they are an existing user data used by DB applications.
> To achieve that I will create another linear device to simulate the
> original extent's offsets which shall be mapped to the created mirrored
> device so, the client will continue to read and write the same offsets.
>



Aren't you trying to reinvent dm-replicator target ?
(available as an extra kernel patch)

Maybe you should first describe exactly what are you trying to achieve.
I'd guess there would be better ways to achieve that goal.

Updating kernel tables is expensive operation - especially if you plan to have
its size in the range of multiple megabytes - so it looks like wrong plan...

Zdenek

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-03-2011, 07:58 AM
"Eli Malul"
 
Default Huge memory allocation

I would like to accelerate read IO performance for user data which
resides on one machine (with low IO performance due to slow media) and
might be scattered on many different extents by mirroring these extents
to another machine with much better IO performance and direct read
requests to that machine (I already added a patch to the dm-raid1.c to
set preferred read capability).

Any suggestions would be appreciated...

-----Original Message-----
From: Zdenek Kabelac [mailto:zkabelac@redhat.com]
Sent: Thursday, March 03, 2011 10:42 AM
To: undisclosed-recipients
Cc: Eli Malul; device-mapper development
Subject: Re: [dm-devel] Huge memory allocation

Dne 3.3.2011 09:05, Eli Malul napsal(a):
> I am expecting to have lots of (up to million) scattered extents
across
> some volumes which I am required to mirror.
> Since mirror mapped device with a table that large consume unbearable
> amount of memory (e.g. for 10,000 extents I saw about 6 Giga of memory
> allocated by the device-mapper) I am going to create two linear
devices
> which maps these extents and mirror them.
>
> In addition, I am required to preserve the original extent's offsets
> since they are an existing user data used by DB applications.
> To achieve that I will create another linear device to simulate the
> original extent's offsets which shall be mapped to the created
mirrored
> device so, the client will continue to read and write the same
offsets.
>



Aren't you trying to reinvent dm-replicator target ?
(available as an extra kernel patch)

Maybe you should first describe exactly what are you trying to achieve.
I'd guess there would be better ways to achieve that goal.

Updating kernel tables is expensive operation - especially if you plan
to have
its size in the range of multiple megabytes - so it looks like wrong
plan...

Zdenek

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 03-03-2011, 09:00 AM
Zdenek Kabelac
 
Default Huge memory allocation

Dne 3.3.2011 09:58, Eli Malul napsal(a):
> I would like to accelerate read IO performance for user data which
> resides on one machine (with low IO performance due to slow media) and
> might be scattered on many different extents by mirroring these extents
> to another machine with much better IO performance and direct read
> requests to that machine (I already added a patch to the dm-raid1.c to
> set preferred read capability).
>
> Any suggestions would be appreciated...

There were some projects like dm cache and probably few others.
(http://visa.cis.fiu.edu/ming/dmcache/)
You will need to create a new dm target for the thing you try to achieve.
Handling this in userspace could only serve for prototype thing.

Structures in libdm are not designed to work efficiently with millions of
extents passed to kernel through ioctl operation - this path isn't probably
the best one...

You may still want to check dm-replicator or drdb technology.

But it all depends on how do you plan to synchronize above the block level,
and how the write operation is supposed to handled.

Zdenek

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 01:48 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org