[linux-lvm] file system larger than lv

[linux-lvm] file system larger than lv

[Jonathan S. Polacheck]

I posted the following to the ext2 help forum and got the included
response;

By: jpolache ( Jon Polacheck )
 reasize2fs fails
2002-11-13 13:23
I have an lvm volume for my /usr filesystem on a Mandrake 8.1 server. I did
a
lvextend, and am now trying to resize the filesystem into the logical
volume.

I went to runlevel 1, unmounted all my filesystems (umount -a) and ran
e2fsck on /dev/sys/usr. I got output indicating that the superblock size
was 793600 blocks and the "physical" size was 665600 blocks.

e2fsck ended with the following;

Error scanning inodes (336000): can't read next inode

/dev/sys/usr: 13494/400000 files (1.2% non-contiguous), 578502/793600
blocks

When I then run resize2fs, I get the following output;

resize2fs: Can't read a block bitmap while trying to resize /dev/sys/usr.
The file system on /dev/sys/usr is now 665600 blocks long.

Any suggestions?

By: tytso ( Theodore Ts'o )
 RE: reasize2fs fails
2002-11-14 07:28
That's an LVM problem. e2fsck was very clear when it told you that device
was smaller than the size specified in the superblock.

...there was probably severe damage to the filesystem which was done,
because resize2fs attempted to shrink the filesystem down to 665600 from
the superblock size of 793600. But since LVM had apparently already gotten
the idea that the device was now smaller, any data that was stored in the
blocks between 665600 and 793600 has been lost.

......................................................................................

Any suggestions as to how I can proceed from here?

Re: [linux-lvm] file system larger than lv

[Heinz J . Mauelshagen]

On Thu, Nov 14, 2002 at 09:35:06AM -0600, Jonathan S. Polacheck wrote:
> I posted the following to the ext2 help forum and got the included
> response;
> 
> By: jpolache ( Jon Polacheck )
>  reasize2fs fails
> 2002-11-13 13:23
> I have an lvm volume for my /usr filesystem on a Mandrake 8.1 server. I did
> a
> lvextend, and am now trying to resize the filesystem into the logical
> volume.
> 
> I went to runlevel 1, unmounted all my filesystems (umount -a) and ran
> e2fsck on /dev/sys/usr. I got output indicating that the superblock size
> was 793600 blocks and the "physical" size was 665600 blocks.
> 
> e2fsck ended with the following;
> 
> Error scanning inodes (336000): can't read next inode
> 
> /dev/sys/usr: 13494/400000 files (1.2% non-contiguous), 578502/793600
> blocks

This was the point in time were you better had stopped and asked for advice :(

> 
> When I then run resize2fs, I get the following output;
> 
> resize2fs: Can't read a block bitmap while trying to resize /dev/sys/usr.
> The file system on /dev/sys/usr is now 665600 blocks long.

Boom. As Ted said: your fs is now smaller and you lost data.

You probably didn't run lvextend but lvreduce instead, which made the logical
volume smaller that the actual filesystem (similar to configuring a partition
conatinig an ext2 fs smaller). LVM1 contains the e2fsadm tool which prevents
you form doing things like that.
The lvreduce alone wouldn't have been the end of the day, because you still had
the old configuration with the prevoius LV size and mapping in the LVM metadata
archive. Deactivating the VG and restoring that state of the metadata would
have cut it.

Now that you run resize2fs and Ted (the ext2/resize2fs guru) can't help
you, it is tape archive time :(


> 
> Any suggestions?
> 
> By: tytso ( Theodore Ts'o )
>  RE: reasize2fs fails
> 2002-11-14 07:28
> That's an LVM problem. e2fsck was very clear when it told you that device
> was smaller than the size specified in the superblock.
> 
> ...there was probably severe damage to the filesystem which was done,
> because resize2fs attempted to shrink the filesystem down to 665600 from
> the superblock size of 793600. But since LVM had apparently already gotten
> the idea that the device was now smaller, any data that was stored in the
> blocks between 665600 and 793600 has been lost.
> 
> ......................................................................................
> 
> Any suggestions as to how I can proceed from here?
> 
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] file system larger than lv

[lvm]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

On Fri, Nov 15, 2002 at 11:58:31AM +0100, Heinz J . Mauelshagen wrote:
> 

Heinz,

> LVM1 contains the e2fsadm tool which prevents
> you form doing things like that.

I know we are never going to be able to stop everybody who _really_
wants to shoot themselves in the foot from doing so, but I wonder,
perhaps if there should be "something extra" that needs to be done to
manipulate the size of volumes with filesystems on them (i.e. probe
the lv to see what's on it) directly (i.e.  lvreduce, lvexpand).  This
would of course be used to encourage the use of the convenience tools
like e2fsadm.

Perhaps an environment variable or an "expert switch" on the command
line or something.  Not using the switch or setting the env. variable
would cause a probe of the lv and if there was found to be a
filesystem on it, it would prompt the user to use a convenience tool
(for that filesystem type) to perform his task, or set the
switch/variable, if he really wanted to go ahead.

Or maybe this is all just too much handholding.

b.

-- 
Brian J. Murrell

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [linux-lvm] file system larger than lv

[Heinz J . Mauelshagen]

Brian,

yes, at the end of the day you can't prevent people with the necessary
credentials from shooting themselves in the foot anyways.
That occasionally includes me.
At least at ~4pm in the morning ;)

Because LVM is a block layer service transparent to filesystems or any other
arbitrary block device user, it should just cover the necessary block device
functionality.

Putting additional overloading block/filesystem layer services not necessarily
needed there into the kernel is unlikely to be accepted either IMO.

Controlling LVM block device and filesystem changes in userspace with an
(e2)fsadm tool is a "helping hand" for the unexperienced, not limiting
the experienced user.
This is our prefered way to go.


On Fri, Nov 15, 2002 at 07:27:08AM -0500, lvm@interlinx.bc.ca wrote:
> On Fri, Nov 15, 2002 at 11:58:31AM +0100, Heinz J . Mauelshagen wrote:
> > 
> 
> Heinz,
> 
> > LVM1 contains the e2fsadm tool which prevents
> > you form doing things like that.
> 
> I know we are never going to be able to stop everybody who _really_
> wants to shoot themselves in the foot from doing so, but I wonder,
> perhaps if there should be "something extra" that needs to be done to
> manipulate the size of volumes with filesystems on them (i.e. probe
> the lv to see what's on it) directly (i.e.  lvreduce, lvexpand).  This
> would of course be used to encourage the use of the convenience tools
> like e2fsadm.
> 
> Perhaps an environment variable or an "expert switch" on the command
> line or something.  Not using the switch or setting the env. variable
> would cause a probe of the lv and if there was found to be a
> filesystem on it, it would prompt the user to use a convenience tool
> (for that filesystem type) to perform his task, or set the
> switch/variable, if he really wanted to go ahead.
> 
> Or maybe this is all just too much handholding.
> 
> b.
> 
> -- 
> Brian J. Murrell



-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] file system larger than lv

[lvm]

[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]

On Fri, Nov 15, 2002 at 01:54:24PM +0100, Heinz J . Mauelshagen wrote:
> 
> Brian,

Hi Heinz.

> yes, at the end of the day you can't prevent people with the necessary
> credentials from shooting themselves in the foot anyways.
> That occasionally includes me.
> At least at ~4pm in the morning ;)

I hear ya.  Me too.  :-)

> Because LVM is a block layer service transparent to filesystems or any other
> arbitrary block device user, it should just cover the necessary block device
> functionality.

I don't disagree with that.

> Putting additional overloading block/filesystem layer services not necessarily
> needed there into the kernel is unlikely to be accepted either IMO.

No.  No.  Not in the kernel.  I mean the user space tools can simply
check what data is on the block device (i.e. look for a known
signature of given filesystems) and see if it can determine if it is
indeed a filesystem.

> Controlling LVM block device and filesystem changes in userspace with an
> (e2)fsadm tool is a "helping hand" for the unexperienced, not limiting
> the experienced user.
> This is our prefered way to go.

That is fair enough.  And I don't care that strongly about this issue,
but just thought of how many tools (in their "interactive mode"
anyway) stop and ask a user before they are about to do something
potentially disasterous.

b.

-- 
Brian J. Murrell

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [linux-lvm] file system larger than lv

[Ragnar Kjørstad]

> > Putting additional overloading block/filesystem layer services not necessarily
> > needed there into the kernel is unlikely to be accepted either IMO.
> 
> No.  No.  Not in the kernel.  I mean the user space tools can simply
> check what data is on the block device (i.e. look for a known
> signature of given filesystems) and see if it can determine if it is
> indeed a filesystem.

First of all it's not possible to detect if the device includes a valid
filesystem. You can only check for know filesystems and I don't think it
would be a good idea for lvm to include a list of filesystem-signatures.

Second, reducing the size of a device is just as dangerous if there is
something else (say a datbase) on that device.

So, if anything, I think lvreduce should always warn the user that this
is a dangerous operation.



-- 
Ragnar Kjørstad
Big Storage

Re: [linux-lvm] file system larger than lv

[Heinz J . Mauelshagen]

On Sat, Nov 16, 2002 at 02:59:42AM +0100, Ragnar Kjørstad wrote:
> > > Putting additional overloading block/filesystem layer services not necessarily
> > > needed there into the kernel is unlikely to be accepted either IMO.
> > 
> > No.  No.  Not in the kernel.  I mean the user space tools can simply
> > check what data is on the block device (i.e. look for a known
> > signature of given filesystems) and see if it can determine if it is
> > indeed a filesystem.
> 
> First of all it's not possible to detect if the device includes a valid
> filesystem. You can only check for know filesystems and I don't think it
> would be a good idea for lvm to include a list of filesystem-signatures.
> 
> Second, reducing the size of a device is just as dangerous if there is
> something else (say a datbase) on that device.
> 
> So, if anything, I think lvreduce should always warn the user that this
> is a dangerous operation.
> 

And it does that since used by dinoaurs ;)

> 
> 
> -- 
> Ragnar Kjørstad
> Big Storage
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] file system larger than lv

[Heinz J . Mauelshagen]

On Fri, Nov 15, 2002 at 08:48:20AM -0500, lvm@interlinx.bc.ca wrote:
> On Fri, Nov 15, 2002 at 01:54:24PM +0100, Heinz J . Mauelshagen wrote:
> > 
> > Brian,
> 
> Hi Heinz.
> 
> > yes, at the end of the day you can't prevent people with the necessary
> > credentials from shooting themselves in the foot anyways.
> > That occasionally includes me.
> > At least at ~4pm in the morning ;)
> 
> I hear ya.  Me too.  :-)

:)

> 
> > Because LVM is a block layer service transparent to filesystems or any other
> > arbitrary block device user, it should just cover the necessary block device
> > functionality.
> 
> I don't disagree with that.
> 
> > Putting additional overloading block/filesystem layer services not necessarily
> > needed there into the kernel is unlikely to be accepted either IMO.
> 
> No.  No.  Not in the kernel.  I mean the user space tools can simply
> check what data is on the block device (i.e. look for a known
> signature of given filesystems) and see if it can determine if it is
> indeed a filesystem.

Yep. We share the same opinion I guess.
The user space tool shall be pattern configurable in order to "learn" about
new filesystem types (config file ala /etc/magic).

> 
> > Controlling LVM block device and filesystem changes in userspace with an
> > (e2)fsadm tool is a "helping hand" for the unexperienced, not limiting
> > the experienced user.
> > This is our prefered way to go.
> 
> That is fair enough.  And I don't care that strongly about this issue,
> but just thought of how many tools (in their "interactive mode"
> anyway) stop and ask a user before they are about to do something
> potentially disasterous.

lvreduce warns.
As mkfs does ;)

> 
> b.
> 
> -- 
> Brian J. Murrell



-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-