All of lore.kernel.org
 help / color / mirror / Atom feed
* [linux-lvm] Upgrade to 0.9.1b8 went ok but....
@ 2001-07-25 21:57 Gonyou, Austin
  2001-07-26  9:46 ` Joe Thornber
  2001-07-26 12:16 ` Dave Alden
  0 siblings, 2 replies; 6+ messages in thread
From: Gonyou, Austin @ 2001-07-25 21:57 UTC (permalink / raw)
  To: 'linux-lvm@sistina.com'

The Devices won't mount for some reason. Here is the ouput I get from trying
to mount an XFS LVM Volume:

-----snip-----
[root@BurnBox /root]# mount -t xfs /dev/web/webvol1 /web/            
mount: wrong fs type, bad option, bad superblock on /dev/web/webvol1,
       or too many mounted file systems                              
[root@BurnBox /root]# xfs_check /dev/web/webvol1                     
xfs_check: unexpected XFS SB magic number 0x484d0200                 
bad superblock magic number 484d0200, giving up                      
[root@BurnBox /root]#                                                
-----snip-----

If I run xfs_repair, it can't find the superblock either. 

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com 

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [linux-lvm] Upgrade to 0.9.1b8 went ok but....
  2001-07-25 21:57 [linux-lvm] Upgrade to 0.9.1b8 went ok but Gonyou, Austin
@ 2001-07-26  9:46 ` Joe Thornber
  2001-07-26 12:16 ` Dave Alden
  1 sibling, 0 replies; 6+ messages in thread
From: Joe Thornber @ 2001-07-26  9:46 UTC (permalink / raw)
  To: linux-lvm

On Wed, Jul 25, 2001 at 04:57:06PM -0500, Gonyou, Austin wrote:
> The Devices won't mount for some reason. Here is the ouput I get from trying
> to mount an XFS LVM Volume:

<snip>

looks like it's got the positions of the PE's wrong.  Can you
pvdisplay -v a couple of your pv's and note down the position of the
first PE's.  Then I suggest you move back to beta7 using pvversion -1,
and check you can mount XFS there.  If you can, do a pvversion -v
again and see if the PE positions are the same.  Either mail your
results to the list (not *all* the pvversion output, just the first
PE's), or try and find AJ or I on irc.openprojects.net #lvm.

- Joe

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [linux-lvm] Upgrade to 0.9.1b8 went ok but....
  2001-07-25 21:57 [linux-lvm] Upgrade to 0.9.1b8 went ok but Gonyou, Austin
  2001-07-26  9:46 ` Joe Thornber
@ 2001-07-26 12:16 ` Dave Alden
  2001-07-26 12:43   ` Joe Thornber
  1 sibling, 1 reply; 6+ messages in thread
From: Dave Alden @ 2001-07-26 12:16 UTC (permalink / raw)
  To: linux-lvm

Hi,

  Are you aware that the XFS folks modified LVM to work with XFS (something
about a new ioctl or such)?  They state that if you install the latest
patches, you'll back out the XFS-specific changes which can cause you to
lose your XFS filesystem.  For more info, see the thread with a subject
of "When LVM-0.9.1beta7 will be merged to XFS cvs tree?" from:

http://oss.sgi.com/projects/xfs/mail_archive/0107/threads.html#00127

My understanding is that this applies to any LVM patches (including the beta8
patches).

...dave alden

On Wed, Jul 25, 2001 at 04:57:06PM -0500, Gonyou, Austin wrote:
> The Devices won't mount for some reason. Here is the ouput I get from trying
> to mount an XFS LVM Volume:
> 
> -----snip-----
> [root@BurnBox /root]# mount -t xfs /dev/web/webvol1 /web/            
> mount: wrong fs type, bad option, bad superblock on /dev/web/webvol1,
>        or too many mounted file systems                              
> [root@BurnBox /root]# xfs_check /dev/web/webvol1                     
> xfs_check: unexpected XFS SB magic number 0x484d0200                 
> bad superblock magic number 484d0200, giving up                      
> [root@BurnBox /root]#                                                
> -----snip-----
> 
> If I run xfs_repair, it can't find the superblock either. 
> 
> -- 
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-796-9023
> email: austin@coremetrics.com 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [linux-lvm] Upgrade to 0.9.1b8 went ok but....
  2001-07-26 12:16 ` Dave Alden
@ 2001-07-26 12:43   ` Joe Thornber
  0 siblings, 0 replies; 6+ messages in thread
From: Joe Thornber @ 2001-07-26 12:43 UTC (permalink / raw)
  To: linux-lvm

On Thu, Jul 26, 2001 at 08:16:33AM -0400, Dave Alden wrote:
> Hi,
> 
>   Are you aware that the XFS folks modified LVM to work with XFS (something
> about a new ioctl or such)?  They state that if you install the latest
> patches, you'll back out the XFS-specific changes which can cause you to
> lose your XFS filesystem.  For more info, see the thread with a subject
> of "When LVM-0.9.1beta7 will be merged to XFS cvs tree?" from:
> 
> http://oss.sgi.com/projects/xfs/mail_archive/0107/threads.html#00127
> 
> My understanding is that this applies to any LVM patches (including the beta8
> patches).

No I wasn't aware of this, though Patrick may be since he uses XFS.

from http://oss.sgi.com/projects/xfs/mail_archive/0107/msg00132.html:

> All block devices in a XFS kernel need a special patch to add an ioctl
> to set the logical block size. The original poster probably didn't add
> that ioctl to his new hacked in LVM; which will cause all kinds of 
> problems with xfs user tools and also probably file system corruption.

^ permalink raw reply	[flat|nested] 6+ messages in thread
* RE: [linux-lvm] Upgrade to 0.9.1b8 went ok but....
@ 2001-07-26 19:28 Gonyou, Austin
  0 siblings, 0 replies; 6+ messages in thread
From: Gonyou, Austin @ 2001-07-26 19:28 UTC (permalink / raw)
  To: 'linux-lvm@sistina.com'

This would make some sense since I just blew my fs away and recreated them.
Then they mounted fine. 

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com 

> -----Original Message-----
> From: Joe Thornber [mailto:thornber@btconnect.com]
> Sent: Thursday, July 26, 2001 7:43 AM
> To: linux-lvm@sistina.com
> Subject: Re: [linux-lvm] Upgrade to 0.9.1b8 went ok but....
> 
> 
> On Thu, Jul 26, 2001 at 08:16:33AM -0400, Dave Alden wrote:
> > Hi,
> > 
> >   Are you aware that the XFS folks modified LVM to work 
> with XFS (something
> > about a new ioctl or such)?  They state that if you install 
> the latest
> > patches, you'll back out the XFS-specific changes which can 
> cause you to
> > lose your XFS filesystem.  For more info, see the thread 
> with a subject
> > of "When LVM-0.9.1beta7 will be merged to XFS cvs tree?" from:
> > 
> > http://oss.sgi.com/projects/xfs/mail_archive/0107/threads.html#00127
> > 
> > My understanding is that this applies to any LVM patches 
> (including the beta8
> > patches).
> 
> No I wasn't aware of this, though Patrick may be since he uses XFS.
> 
> from http://oss.sgi.com/projects/xfs/mail_archive/0107/msg00132.html:
> 
> > All block devices in a XFS kernel need a special patch to 
> add an ioctl
> > to set the logical block size. The original poster probably 
> didn't add
> > that ioctl to his new hacked in LVM; which will cause all kinds of 
> > problems with xfs user tools and also probably file system 
> corruption.
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread
* RE: [linux-lvm] Upgrade to 0.9.1b8 went ok but....
@ 2001-07-27 18:33 Dale Stephenson
  0 siblings, 0 replies; 6+ messages in thread
From: Dale Stephenson @ 2001-07-27 18:33 UTC (permalink / raw)
  To: 'linux-lvm@sistina.com'

On the subject of XFS specific changes to LVM:

I happen to have 2.4.7 XFS handy.  The differences between it and beta 6 (on
which it is based) are four in number:

1) Stripping out the OS-version conditionals not applicable to 2.4.7

2) Changing *_hardblock_* to *_hardsect_*, needed for 2.4.4 or later
compilation.  I assume beta8 has this sort of fix in for versions greater
than 2.4.3.

3) Fixing a bug using b_blocknr/b_dev in lvm_map, provided by Jens Axboe.
Beta7 fixed the same bug (code by Heinz), but the actual code of the fix
doesn't match exactly.

4) The extra ioctl, which is a real quickie:

	case BLKBSZGET:
	case BLKBSZSET:
		return blk_ioctl (inode->i_rdev, command, a);

Beta 7 didn't have that, I don't know if beta 8 (conditionally?) includes
it.

Here's the actual differences in patch form, for differences 2, 3, and 4 (I
stripped the OS-version conditionals).

--- LVM_0_9_1/kernel/lvm.c	Fri Jul 27 11:14:57 2001
+++ /usr/src/redhat/BUILD/linux/drivers/md/lvm.c	Fri Jul 27 10:37:38
2001
@@ -194,6 +194,11 @@
  *               - factored lvm_do_pv_flush out of lvm_chr_ioctl (HM)
  *    09/03/2001 - Added _lock_open_count to ensure we only drop the lock
  *                 when the locking process closes.
+ *    05/04/2001 - lvm_map bugs: don't use b_blocknr/b_dev in lvm_map, it
+ *                 destroys stacking devices. call b_end_io on failed maps.
+ *                 (Jens Axboe)
+ *    30/04/2001 - replace get_hardblock_size() with get_hardsect_size()
for
+ *                 2.4.4 kernel.
  *
  */
 
@@ -304,7 +309,7 @@
 static int lvm_do_vg_rename(vg_t *, void *);
 static int lvm_do_vg_remove(int);
 static void lvm_geninit(struct gendisk *);
-static void __update_hardblocksize(lv_t *lv);
+static void __update_hardsectsize(lv_t *lv);
 
 
 #ifdef LVM_HD_NAME
@@ -935,6 +940,9 @@
 			return -EFAULT;
 		break;
 
+	case BLKBSZGET:
+        case BLKBSZSET:
+                return blk_ioctl (inode->i_rdev, command, a);
 
 	case HDIO_GETGEO:
 		/* get disk geometry */
@@ -983,12 +991,11 @@
 		break;
 
 	case LV_BMAP:
-                /* turn logical block into (dev_t, block).  non privileged.
*/
-                /* don't bmap a snapshot, since the mapping can change */
-		if(lv_ptr->lv_access & LV_SNAPSHOT)
+		/* turn logical block into (dev_t, block). non privileged.
*/
+		/* don't bmap a snapshot, since the mapping can change */
+		if (lv_ptr->lv_access & LV_SNAPSHOT)
 			return -EPERM;
 
-		/* turn logical block into (dev_t, block). non privileged.
*/
 		return lvm_user_bmap(inode, (struct lv_bmap *) arg);
 		break;
 
@@ -1079,16 +1086,17 @@
 		return -EFAULT;
 
 	memset(&bh,0,sizeof bh);
-	bh.b_blocknr = block;
-	bh.b_dev = bh.b_rdev = inode->i_rdev;
+	bh.b_rsector = block;
+	bh.b_dev = bh.b_rdev = inode->i_dev;
 	bh.b_size = lvm_get_blksize(bh.b_dev);
 	if ((err=lvm_map(&bh, READ)) < 0)  {
 		printk("lvm map failed: %d\n", err);
 		return -EINVAL;
 	}
 
-	return (put_user(kdev_t_to_nr(bh.b_rdev), &user_result->lv_dev) ||
-		put_user(bh.b_rsector/(bh.b_size>>9),
&user_result->lv_block));
+	return put_user(kdev_t_to_nr(bh.b_rdev), &user_result->lv_dev) ||
+	       put_user(bh.b_rsector/(bh.b_size>>9), &user_result->lv_block)
?
+	       -EFAULT : 0;
 }
 
 
@@ -1109,7 +1117,7 @@
 	ulong index;
 	ulong pe_start;
 	ulong size = bh->b_size >> 9;
-	ulong rsector_org = bh->b_blocknr * size;
+	ulong rsector_org = bh->b_rsector;
 	ulong rsector_map;
 	kdev_t rdev_map;
 	vg_t *vg_this = vg[VG_BLK(minor)];
@@ -1273,10 +1281,15 @@
 /*
  * make request function
  */
-static int lvm_make_request_fn(request_queue_t *q,
-			       int rw,
-			       struct buffer_head *bh) {
-	return (lvm_map(bh, rw) < 0) ? 0 : 1;
+static int lvm_make_request_fn(request_queue_t *q, 
+			       int rw, 
+			       struct buffer_head *bh) 
+{
+	if (lvm_map(bh, rw) >= 0)
+		return 1;
+
+	buffer_IO_error(bh);
+	return 0;
 }
 
 
@@ -1380,7 +1393,7 @@
 					lv_ptr->lv_current_pe[le].pe =
 					    le_remap_req.new_pe;
 
-					__update_hardblocksize(lv_ptr);
+					__update_hardsectsize(lv_ptr);
 					return 0;
 				}
 			}
@@ -1736,31 +1749,31 @@
 }
 
 
-static void __update_hardblocksize(lv_t *lv) {
+static void __update_hardsectsize(lv_t *lv) {
 	int le, e;
-	int max_hardblocksize = 0, hardblocksize;
+	int max_hardsectsize = 0, hardsectsize;
 
 	for (le = 0; le < lv->lv_allocated_le; le++) {
-		hardblocksize =
get_hardblocksize(lv->lv_current_pe[le].dev);
-		if (hardblocksize == 0)
-			hardblocksize = 512;
-		if (hardblocksize > max_hardblocksize)
-			max_hardblocksize = hardblocksize;
+		hardsectsize = get_hardsect_size(lv->lv_current_pe[le].dev);
+		if (hardsectsize == 0)
+			hardsectsize = 512;
+		if (hardsectsize > max_hardsectsize)
+			max_hardsectsize = hardsectsize;
 	}
 
 	if (lv->lv_access & LV_SNAPSHOT) {
 		for (e = 0; e < lv->lv_remap_end; e++) {
-			hardblocksize =
-				get_hardblocksize(
+			hardsectsize =
+				get_hardsect_size(
 					lv->lv_block_exception[e].rdev_new);
-			if (hardblocksize == 0)
-				hardblocksize = 512;
-			if (hardblocksize > max_hardblocksize)
-				max_hardblocksize = hardblocksize;
+			if (hardsectsize == 0)
+				hardsectsize = 512;
+			if (hardsectsize > max_hardsectsize)
+				max_hardsectsize = hardsectsize;
 		}
 	}
 
-	lvm_hardsectsizes[MINOR(lv->lv_dev)] = max_hardblocksize;
+	lvm_hardsectsizes[MINOR(lv->lv_dev)] = max_hardsectsize;
 }
 
 /*
@@ -1945,7 +1958,7 @@
 	vg_ptr->lv_cur++;
 	lv_ptr->lv_status = lv_status_save;
 
-	__update_hardblocksize(lv_ptr);
+	__update_hardsectsize(lv_ptr);
 
 	/* optionally add our new snapshot LV */
 	if (lv_ptr->lv_access & LV_SNAPSHOT) {
@@ -2299,13 +2312,13 @@
 					= old_lv->lv_size;
 				lvm_size[MINOR(snap->lv_dev)] =
 					old_lv->lv_size >> 1;
-				__update_hardblocksize(snap);
+				__update_hardsectsize(snap);
 				up(&snap->lv_snapshot_sem);
 			}
 		}
 	}
 
-	__update_hardblocksize(old_lv);
+	__update_hardsectsize(old_lv);
 	up(&old_lv->lv_snapshot_sem);
 
 	return 0;

----
Dale J. Stephenson
steph@connex.com 

> -----Original Message-----
> From: Joe Thornber [mailto:thornber@btconnect.com]
> Sent: Thursday, July 26, 2001 5:43 AM
> To: linux-lvm@sistina.com
> Subject: Re: [linux-lvm] Upgrade to 0.9.1b8 went ok but....
> 
> 
> On Thu, Jul 26, 2001 at 08:16:33AM -0400, Dave Alden wrote:
> > Hi,
> > 
> >   Are you aware that the XFS folks modified LVM to work 
> with XFS (something
> > about a new ioctl or such)?  They state that if you install 
> the latest
> > patches, you'll back out the XFS-specific changes which can 
> cause you to
> > lose your XFS filesystem.  For more info, see the thread 
> with a subject
> > of "When LVM-0.9.1beta7 will be merged to XFS cvs tree?" from:
> > 
> > http://oss.sgi.com/projects/xfs/mail_archive/0107/threads.html#00127
> > 
> > My understanding is that this applies to any LVM patches 
> (including the beta8
> > patches).
> 
> No I wasn't aware of this, though Patrick may be since he uses XFS.
> 
> from http://oss.sgi.com/projects/xfs/mail_archive/0107/msg00132.html:
> 
> > All block devices in a XFS kernel need a special patch to 
> add an ioctl
> > to set the logical block size. The original poster probably 
> didn't add
> > that ioctl to his new hacked in LVM; which will cause all kinds of 
> > problems with xfs user tools and also probably file system 
> corruption.
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2001-07-27 18:33 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-07-25 21:57 [linux-lvm] Upgrade to 0.9.1b8 went ok but Gonyou, Austin
2001-07-26  9:46 ` Joe Thornber
2001-07-26 12:16 ` Dave Alden
2001-07-26 12:43   ` Joe Thornber
  -- strict thread matches above, loose matches on Subject: below --
2001-07-26 19:28 Gonyou, Austin
2001-07-27 18:33 Dale Stephenson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.