Hi,
Here are the latest patches from the stable device-mapper tree.
Please apply.
Thanks,
- Joe
When setting the size of a Device-Mapper device in the gendisk entry,
also try to set the size of the corresponding block_device entry's
inode. This is necessary to allow online device/filesystem resizing to
work correctly. [Kevin Corry]
--- diff/drivers/md/dm.c 2003-09-30 15:46:14.000000000 +0100
+++ source/drivers/md/dm.c 2003-11-25 15:36:59.000000000 +0000
@@ -666,6 +666,20 @@
up_write(&md->lock);
}
+static void __set_size(struct gendisk *disk, sector_t size)
+{
+ struct block_device *bdev;
+
+ set_capacity(disk, size);
+ bdev = bdget_disk(disk, 0);
+ if (bdev) {
+ down(&bdev->bd_inode->i_sem);
+ i_size_write(bdev->bd_inode, size << SECTOR_SHIFT);
+ up(&bdev->bd_inode->i_sem);
+ bdput(bdev);
+ }
+}
+
static int __bind(struct mapped_device *md, struct dm_table *t)
{
request_queue_t *q = md->queue;
@@ -673,7 +687,7 @@
md->map = t;
size = dm_table_get_size(t);
- set_capacity(md->disk, size);
+ __set_size(md->disk, size);
if (size == 0)
return 0;
@@ -692,7 +706,6 @@
dm_table_event_callback(md->map, NULL, NULL);
dm_table_put(md->map);
md->map = NULL;
- set_capacity(md->disk, 0);
}
/*
The dm table size is always known in advance, so we can specify it in
dm_table_create(), rather than relying on dynamic resizing.
--- diff/drivers/md/dm-ioctl-v1.c 2003-09-30 15:46:14.000000000 +0100
+++ source/drivers/md/dm-ioctl-v1.c 2003-11-25 15:47:38.000000000 +0000
@@ -566,7 +566,7 @@
if (r)
return r;
- r = dm_table_create(&t, get_mode(param));
+ r = dm_table_create(&t, get_mode(param), param->target_count);
if (r)
return r;
@@ -894,7 +894,7 @@
struct mapped_device *md;
struct dm_table *t;
- r = dm_table_create(&t, get_mode(param));
+ r = dm_table_create(&t, get_mode(param), param->target_count);
if (r)
return r;
--- diff/drivers/md/dm-ioctl-v4.c 2003-09-30 15:46:14.000000000 +0100
+++ source/drivers/md/dm-ioctl-v4.c 2003-11-25 15:47:38.000000000 +0000
@@ -872,7 +872,7 @@
struct hash_cell *hc;
struct dm_table *t;
- r = dm_table_create(&t, get_mode(param));
+ r = dm_table_create(&t, get_mode(param), param->target_count);
if (r)
return r;
--- diff/drivers/md/dm-table.c 2003-11-25 15:24:57.000000000 +0000
+++ source/drivers/md/dm-table.c 2003-11-25 15:47:38.000000000 +0000
@@ -202,7 +202,7 @@
return 0;
}
-int dm_table_create(struct dm_table **result, int mode)
+int dm_table_create(struct dm_table **result, int mode, unsigned num_targets)
{
struct dm_table *t = kmalloc(sizeof(*t), GFP_NOIO);
@@ -213,8 +213,12 @@
INIT_LIST_HEAD(&t->devices);
atomic_set(&t->holders, 1);
- /* allocate a single nodes worth of targets to begin with */
- if (alloc_targets(t, KEYS_PER_NODE)) {
+ if (!num_targets)
+ num_targets = KEYS_PER_NODE;
+
+ num_targets = dm_round_up(num_targets, KEYS_PER_NODE);
+
+ if (alloc_targets(t, num_targets)) {
kfree(t);
t = NULL;
return -ENOMEM;
--- diff/drivers/md/dm.h 2003-08-20 14:16:09.000000000 +0100
+++ source/drivers/md/dm.h 2003-11-25 15:47:38.000000000 +0000
@@ -95,7 +95,7 @@
* Functions for manipulating a table. Tables are also reference
* counted.
*---------------------------------------------------------------*/
-int dm_table_create(struct dm_table **result, int mode);
+int dm_table_create(struct dm_table **result, int mode, unsigned num_targets);
void dm_table_get(struct dm_table *t);
void dm_table_put(struct dm_table *t);
Make the version-4 ioctl interface the default kernel configuration option.
If you have out of date tools you will need to use the v1 interface.
--- diff/drivers/md/Kconfig 2003-10-09 09:47:34.000000000 +0100
+++ source/drivers/md/Kconfig 2003-11-25 15:47:48.000000000 +0000
@@ -138,6 +138,7 @@
config DM_IOCTL_V4
bool "ioctl interface version 4"
depends on BLK_DEV_DM
+ default y
---help---
Recent tools use a new version of the ioctl interface, only
select this option if you intend using such tools.
Make sure that a target has a sensible set of default io restrictions.
--- diff/drivers/md/dm-table.c 2003-11-25 15:47:38.000000000 +0000
+++ source/drivers/md/dm-table.c 2003-11-25 15:47:59.000000000 +0000
@@ -630,6 +630,16 @@
return 0;
}
+static void set_default_limits(struct io_restrictions *rs)
+{
+ rs->max_sectors = MAX_SECTORS;
+ rs->max_phys_segments = MAX_PHYS_SEGMENTS;
+ rs->max_hw_segments = MAX_HW_SEGMENTS;
+ rs->hardsect_size = 1 << SECTOR_SHIFT;
+ rs->max_segment_size = MAX_SEGMENT_SIZE;
+ rs->seg_boundary_mask = -1;
+}
+
int dm_table_add_target(struct dm_table *t, const char *type,
sector_t start, sector_t len, char *params)
{
@@ -642,6 +652,7 @@
tgt = t->targets + t->num_targets;
memset(tgt, 0, sizeof(*tgt));
+ set_default_limits(&tgt->limits);
tgt->type = dm_get_target_type(type);
if (!tgt->type) {
You can no longer call dm_table_event() from interrupt context.
--- diff/drivers/md/dm-table.c 2003-11-25 15:47:59.000000000 +0000
+++ source/drivers/md/dm-table.c 2003-11-25 15:52:15.000000000 +0000
@@ -12,6 +12,7 @@
#include <linux/namei.h>
#include <linux/ctype.h>
#include <linux/slab.h>
+#include <linux/interrupt.h>
#include <asm/atomic.h>
#define MAX_DEPTH 16
@@ -746,22 +747,28 @@
return r;
}
-static spinlock_t _event_lock = SPIN_LOCK_UNLOCKED;
+static DECLARE_MUTEX(_event_lock);
void dm_table_event_callback(struct dm_table *t,
void (*fn)(void *), void *context)
{
- spin_lock_irq(&_event_lock);
+ down(&_event_lock);
t->event_fn = fn;
t->event_context = context;
- spin_unlock_irq(&_event_lock);
+ up(&_event_lock);
}
void dm_table_event(struct dm_table *t)
{
- spin_lock(&_event_lock);
+ /*
+ * You can no longer call dm_table_event() from interrupt
+ * context, use a bottom half instead.
+ */
+ BUG_ON(in_interrupt());
+
+ down(&_event_lock);
if (t->event_fn)
t->event_fn(t->event_context);
- spin_unlock(&_event_lock);
+ up(&_event_lock);
}
sector_t dm_table_get_size(struct dm_table *t)
Joe Thornber wrote:
> Make the version-4 ioctl interface the default kernel configuration option.
> If you have out of date tools you will need to use the v1 interface.
Actually, isn't the proper way to say this "if your tools are older than
X and/or were _not_ built against recent 2.6 headers you need to use the
v1 interface"?
Also, if you're going to change the default you should change the help
text correspondingly.
On Tuesday 25 November 2003 10:47, Kevin P. Fleming wrote:
> Joe Thornber wrote:
> > Make the version-4 ioctl interface the default kernel configuration
> > option. If you have out of date tools you will need to use the v1
> > interface.
>
> Actually, isn't the proper way to say this "if your tools are older than
> X and/or were _not_ built against recent 2.6 headers you need to use the
> v1 interface"?
>
> Also, if you're going to change the default you should change the help
> text correspondingly.
How's this look?
--
Kevin Corry
[email protected]
http://evms.sourceforge.net/
--- a/drivers/md/Kconfig 2003-11-23 19:31:11.000000000 -0600
+++ b/drivers/md/Kconfig 2003-11-25 11:07:00.000000000 -0600
@@ -138,9 +138,11 @@
config DM_IOCTL_V4
bool "ioctl interface version 4"
depends on BLK_DEV_DM
+ default y
---help---
- Recent tools use a new version of the ioctl interface, only
- select this option if you intend using such tools.
+ Recent tools use this new version of the ioctl interface. Only
+ select N for this option if you use out-of-date tools that weren't
+ compiled for this interface (e.g. LVM2 prior to v2.00.00).
endmenu
On Tue, Nov 25, 2003 at 09:47:28AM -0700, Kevin P. Fleming wrote:
> Joe Thornber wrote:
>
> >Make the version-4 ioctl interface the default kernel configuration option.
> >If you have out of date tools you will need to use the v1 interface.
>
> Actually, isn't the proper way to say this "if your tools are older than
> X and/or were _not_ built against recent 2.6 headers you need to use the
> v1 interface"?
>
> Also, if you're going to change the default you should change the help
> text correspondingly.
I would like to remove v1 support very shortly, making v4 the default
for a bit is just the next phase of this process.
For the last few months the tools have supported both v1 and v4
interfaces, allowing people to roll back to older kernels. I will
update the Kconfig help as you suggest to be more specific about the
tool versions.
- Joe
Kevin Corry wrote:
---help---
- Recent tools use a new version of the ioctl interface, only
- select this option if you intend using such tools.
+ Recent tools use this new version of the ioctl interface. Only
+ select N for this option if you use out-of-date tools that weren't
+ compiled for this interface (e.g. LVM2 prior to v2.00.00).
Actually, I don't think LVM2 uses the device mapper ioctls at all; it
use libdevmapper which calls the ioctls on its behalf.
On Tue, Nov 25, 2003 at 04:33:13PM +0000, Joe Thornber wrote:
> Make the version-4 ioctl interface the default kernel configuration option.
> If you have out of date tools you will need to use the v1 interface.
So why do we keep the old version at all?
Joe Thornber wrote:
> For the last few months the tools have supported both v1 and v4
> interfaces, allowing people to roll back to older kernels. I will
> update the Kconfig help as you suggest to be more specific about the
> tool versions.
My biggest concern here is that even if someone downloads the latest
device-mapper tools tarball and compiles it on their system, unless they
specifically point it at 2.6 kernel headers it won't compile in v4 ioctl
support, so they could be unpleasantly surprised. Given the prevailing
sentiment about _not_ updating /usr/include/{linux,asm} to the headers
with a newly-installed kernel (but rather leaving them the same versions
that libc was compiled against) this a pretty likely scenario unless I'm
mistaken...
On Tuesday 25 November 2003 11:16, Kevin P. Fleming wrote:
> Kevin Corry wrote:
>
> ---help---
> - Recent tools use a new version of the ioctl interface, only
> - select this option if you intend using such tools.
> + Recent tools use this new version of the ioctl interface. Only
> + select N for this option if you use out-of-date tools that weren't
> + compiled for this interface (e.g. LVM2 prior to v2.00.00).
>
> Actually, I don't think LVM2 uses the device mapper ioctls at all; it
> use libdevmapper which calls the ioctls on its behalf.
True. I imagine Joe will know the exact version numbers of LVM2 and
libdevmapper that require the old interface. I believe the version I
mentioned is from the appropriate time-frame, though.
--
Kevin Corry
[email protected]
http://evms.sourceforge.net/
Previously Joe Thornber wrote:
> For the last few months the tools have supported both v1 and v4
> interfaces, allowing people to roll back to older kernels.
'last few months' is extremely short for a migration path. Can't we
ditch the v1 interface in 2.7 and allow people to migrate slowly?
Wichert.
--
Wichert Akkerman <[email protected]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
On Tue, Nov 25, 2003 at 10:15:18AM -0700, Kevin P. Fleming wrote:
> Joe Thornber wrote:
>
> >For the last few months the tools have supported both v1 and v4
> >interfaces, allowing people to roll back to older kernels. I will
> >update the Kconfig help as you suggest to be more specific about the
> >tool versions.
>
> My biggest concern here is that even if someone downloads the latest
> device-mapper tools tarball and compiles it on their system, unless they
> specifically point it at 2.6 kernel headers it won't compile in v4 ioctl
> support, so they could be unpleasantly surprised.
The tools build against their own copies of the header files.
- Joe
On Tue, Nov 25, 2003 at 05:20:59PM +0000, Christoph Hellwig wrote:
> On Tue, Nov 25, 2003 at 04:33:13PM +0000, Joe Thornber wrote:
> > Make the version-4 ioctl interface the default kernel configuration option.
> > If you have out of date tools you will need to use the v1 interface.
>
> So why do we keep the old version at all?
See my earlier email where I said I don't want to keep it. Both
versions have only been present while people are migrating.
- Joe
On Tue, Nov 25, 2003 at 06:29:49PM +0100, Wichert Akkerman wrote:
> 'last few months' is extremely short for a migration path. Can't we
> ditch the v1 interface in 2.7 and allow people to migrate slowly?
People still using LVM2/device-mapper userspace components that
don't support v4 really should upgrade them to fix some significant
(unrelated) issues with those old versions.
The v1 interface was broken.
(Not architecture independent. And used __kernel_dev_t.)
The v4 interface fixed things, and is the only version anyone
compiling a new kernel should be using.
The v4 interface has been supported officially since mid-July in
device-mapper 1.0 (with LVM 2.0).
Since then, the userspace component that communicates with device-mapper
(libdevmapper.so) has supported *both* versions simultaneously - so you
don't need to change anything in userspace when switching between
kernels running v1 and v4. (The LVM2 tools talk to libdevmapper.so
which detects and handles the interface version transparently.)
In the current device-mapper tarball that I put on the Sistina FTP site
last Friday v1 support is no longer available by default - it has to be
specifically requested as a configuration option.
Alasdair
--
[email protected]
On Tue, Nov 25, 2003 at 08:18:25PM +0000, Alasdair G Kergon wrote:
> On Tue, Nov 25, 2003 at 06:29:49PM +0100, Wichert Akkerman wrote:
> > 'last few months' is extremely short for a migration path. Can't we
> > ditch the v1 interface in 2.7 and allow people to migrate slowly?
>
> People still using LVM2/device-mapper userspace components that
> don't support v4 really should upgrade them to fix some significant
> (unrelated) issues with those old versions.
>...
The point is IMHO a different one:
Kill the v1 interface before 2.6.0 or in 2.7 .
It's never a good idea to remove something inside a stable kernel series
(e.g. the DRI support for XFree86 4.0 will never be removed from 2.4).
> Alasdair
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, Nov 26, 2003 at 12:45:11AM +0100, Adrian Bunk wrote:
> On Tue, Nov 25, 2003 at 08:18:25PM +0000, Alasdair G Kergon wrote:
> > On Tue, Nov 25, 2003 at 06:29:49PM +0100, Wichert Akkerman wrote:
> > > 'last few months' is extremely short for a migration path. Can't we
> > > ditch the v1 interface in 2.7 and allow people to migrate slowly?
> >
> > People still using LVM2/device-mapper userspace components that
> > don't support v4 really should upgrade them to fix some significant
> > (unrelated) issues with those old versions.
> >...
>
> The point is IMHO a different one:
>
> Kill the v1 interface before 2.6.0 or in 2.7 .
>
> It's never a good idea to remove something inside a stable kernel series
> (e.g. the DRI support for XFree86 4.0 will never be removed from 2.4).
Agreed, we'd like to do it before 2.6.0.
- Joe