[linux-lvm] EXT2 to EXT3 LVM volume on Redhat

[linux-lvm] EXT2 to EXT3 LVM volume on Redhat

[Aslak Sommerfelt Skretting]

Hello.


I've been using LVM for almost a year now, and im extremely satisfied.

I use it on a Redhat 7.2 fileserver with the 2.4.18 kernel.

I've combined 6 ide drives into a logical volume /dev/storage/space with an
EXT2 filesystem on it, totalling around 650gb of storage.

What I am wondering is, would it be wise to convert this filesystem to EXT3?
Or are there risks involved when doing this?


As far as i can understand a simple:

tune2fs -j /dev/storage/space

would create a new journal file, and convert the filesystem to ext3. and a:

tune2fs -i 0 /dev/storage/space

would disable the fsck's that occur now and then (and takes an insane amount
of time on a 650gb filesystem), and are no longer necessary since the
filesystem is EXT3.

and then everything would be ok? or is there more that need to be done?


Is this a complicated process that i might just as well avoid in order not
to damage my data? Or is this pretty straightforward?




Regards

Aslak Sommerfelt Skretting
aslak@skretting.org

Re: [linux-lvm] EXT2 to EXT3 LVM volume on Redhat

[Ben Lutgens]

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

On Tue, Jun 04, 2002 at 10:18:49PM +0200, Aslak Sommerfelt Skretting wrote:
>As far as i can understand a simple:
>
>tune2fs -j /dev/storage/space

Yup. I've done this many times with no problems. 

>
>would create a new journal file, and convert the filesystem to ext3. and a:
>
>tune2fs -i 0 /dev/storage/space
>
>would disable the fsck's that occur now and then (and takes an insane amount
>of time on a 650gb filesystem), and are no longer necessary since the
>filesystem is EXT3.

Don't presume that because it's EXT3 that fscks are no longer necessary.
Only thing the journal guarantees is that your metadata won't become
corrupt (i think journal=data mount option fixes this but will affect
performance and not neccessarily badly). If your filesystem has been
shutdown cleanly many many times you could still has some loss. A fsck
should take care of that.

>and then everything would be ok? or is there more that need to be done?

take backups.
take backups.
take backups.
take backups.

:-)

>
>Is this a complicated process that i might just as well avoid in order not
>to damage my data? Or is this pretty straightforward?

It's pretty straight forward. Did I mention to make sure you have backups?
Oh and the other concern is that you want to make sure you backup before
you get carried away ;-)

Can you tell my tape drive has saved my life and my job once or twice ;-)

-- 
Ben Lutgens				 | http://people.sistina.com/~blutgens/	
System Administrator	 | http://www.sistina.com/
Sistina Software Inc. | 

"I got a wife and kids too but you don't see me out here stealing Imperial
Droids now do ya?"

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

Re: [linux-lvm] EXT2 to EXT3 LVM volume on Redhat

[Aslak Sommerfelt Skretting]

Hi again, and thanks for your quick reply!

>----- Original Message -----
>From: "Ben Lutgens" <blutgens@sistina.com>
>To: <linux-lvm@sistina.com>
>Sent: Tuesday, June 04, 2002 10:31 PM
>Subject: Re: [linux-lvm] EXT2 to EXT3 LVM volume on Redhat
>
>>As far as i can understand a simple:
>>
>>tune2fs -j /dev/storage/space
>
>Yup. I've done this many times with no problems.

Good, odds are in my favour :)

>>
>>would create a new journal file, and convert the filesystem to ext3. and
a:
>>
>>tune2fs -i 0 /dev/storage/space
>>
>>would disable the fsck's that occur now and then (and takes an insane
amount
>>of time on a 650gb filesystem), and are no longer necessary since the
>>filesystem is EXT3.
>
>Don't presume that because it's EXT3 that fscks are no longer necessary.
>Only thing the journal guarantees is that your metadata won't become
>corrupt (i think journal=data mount option fixes this but will affect
>performance and not neccessarily badly). If your filesystem has been
>shutdown cleanly many many times you could still has some loss. A fsck
>should take care of that.

So i skip this tune2fs -i 0 /dev/... option? and let the system fsck the
discs when it wants to?

If so, do i have to change any other settings anywhere to tell fsck that
this is an ext3 filesystem now, or is that first command all I need?

>
>>and then everything would be ok? or is there more that need to be done?
>
>take backups.
>take backups.
>take backups.
>take backups.

Im a poor student, so 650gb x 2 is a little bit out of my league right now.
But yes: point taken.

>
>:-)
>
>>
>>Is this a complicated process that i might just as well avoid in order not
>>to damage my data? Or is this pretty straightforward?
>
>It's pretty straight forward. Did I mention to make sure you have backups?
>Oh and the other concern is that you want to make sure you backup before
>you get carried away ;-)
>
>Can you tell my tape drive has saved my life and my job once or twice ;-)

Im starting to see the picture ;) Im fortunate in the way that so far, i am
the only one using these data :)

>
>--
>Ben Lutgens     | http://people.sistina.com/~blutgens/
>System Administrator  | http://www.sistina.com/
>Sistina Software Inc. |
>
>"I got a wife and kids too but you don't see me out here stealing Imperial
>Droids now do ya?"

No sir, I certainly dont. :)


Regards

Aslak Sommerfelt Skretting
aslak@skretting.org

RE: [linux-lvm] EXT2 to EXT3 LVM volume on Redhat

[Steve Wray]

> From: linux-lvm-admin@sistina.com 
> [mailto:linux-lvm-admin@sistina.com] On Behalf Of Aslak 
> 
> Hi again, and thanks for your quick reply!
> 
> >----- Original Message -----
> >From: "Ben Lutgens" <blutgens@sistina.com>
[big snip]
> >Don't presume that because it's EXT3 that fscks are no longer 
> >necessary. Only thing the journal guarantees is that your metadata 
> >won't become corrupt (i think journal=data mount option fixes this
but 
> >will affect performance and not neccessarily badly). If your
filesystem 
> >has been shutdown cleanly many many times you could still has some 
> >loss. A fsck should take care of that.

Yup journal=data is fantastic; I wouldn't be without it
on the volume that holds the home directories!
I tend to allocate filesystems based on functionality;
tmp gets ext2 cos its fast,
places like /var/spool get XFS cos it can be grown
in a pinch.

Re: [linux-lvm] EXT2 to EXT3 LVM volume on Redhat

[Aslak Sommerfelt Skretting]

This journal=data you talk about, is this an option to be used with the
'mount' command?

----- Original Message -----
From: "Steve Wray" <steve.wray@paradise.net.nz>
To: <linux-lvm@sistina.com>
Sent: Tuesday, June 04, 2002 11:15 PM
Subject: RE: [linux-lvm] EXT2 to EXT3 LVM volume on Redhat


> > From: linux-lvm-admin@sistina.com
> > [mailto:linux-lvm-admin@sistina.com] On Behalf Of Aslak
> >
> > Hi again, and thanks for your quick reply!
> >
> > >----- Original Message -----
> > >From: "Ben Lutgens" <blutgens@sistina.com>
> [big snip]
> > >Don't presume that because it's EXT3 that fscks are no longer
> > >necessary. Only thing the journal guarantees is that your metadata
> > >won't become corrupt (i think journal=data mount option fixes this
> but
> > >will affect performance and not neccessarily badly). If your
> filesystem
> > >has been shutdown cleanly many many times you could still has some
> > >loss. A fsck should take care of that.
>
> Yup journal=data is fantastic; I wouldn't be without it
> on the volume that holds the home directories!
> I tend to allocate filesystems based on functionality;
> tmp gets ext2 cos its fast,
> places like /var/spool get XFS cos it can be grown
> in a pinch.
>
>
>
>
> _______________________________________________
> 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
>
>

Re: [linux-lvm] EXT2 to EXT3 LVM volume on Redhat

[Wolfgang Weisselberg]

Hi, Aslak!

Aslak Sommerfelt Skretting (aslak@skretting.org) wrote 51 lines:

> would disable the fsck's that occur now and then (and takes an insane amount
> of time on a 650gb filesystem), and are no longer necessary since the
> filesystem is EXT3.

Well, no.  Journalling can not even check for errors and
problems due to: 
- program errors in 
  - ext2/ext3 
  - the buffer cache
  - the VFS
- cable problems and connection problems
- harddisk firmware problems 
- the harddisk firmware reordering data without being allowed
  or returning 'OK, all data written' without that being true
- harddisk physical errors/marginal harddisk
- headcrashes
- controller hardware troubles
- controller firmware troubles
- marginal power block, brownouts, spikes, interference
- main memory corruption (you don't have ECC RAM, do you?  And
  even that will not protect you against all multibit errors),
  maybe due to cosmic rays or other radiation, marginal power,
  marginal chips, bad luck, unwise chosen parameters for memory
  refreshes (blame the BIOS!) ...
- Data corruption on the printed board circuit track, inside
  the CPU, in the 1st/2nd/3rd level cache, etc, due to bad
  luck/heat/marginal hardware/powerspikes, interferences,
  whatever.

Journalling only helps against "not cleanly umounting your
partitions forces a *long* fsck", because it guarantees (modulo
hardware/firmware errors and software bugs) that it can return
the metadata (and in some cases, the data) to a known good status
-- which is all that fsck does.

You really want backups.  Neither Journalling nor Raid will
protect you against program errors, nor human errors.  Slip of
finger with rm, typo like "... > important_file", the wrong mouse
click -- you surely can think of more.

-Wolfgang

RE: [linux-lvm] EXT2 to EXT3 LVM volume on Redhat

[Steve Wray]

Yup exactly.
For example I have;
/dev/system/home /home ext3 data=journal 1 2

Its the bomb. I have a hell of a lot of dynamic data
in that /home so in event of a crash there was a big
chance of corruption. Not Any More!!!!!
8-)


> [mailto:linux-lvm-admin@sistina.com] On Behalf Of Aslak 
> Sommerfelt Skretting
> 
> This journal=data you talk about, is this an option to be 
> used with the 'mount' command?
> 
> ----- Original Message -----
> From: "Steve Wray" <steve.wray@paradise.net.nz>
> To: <linux-lvm@sistina.com>
> Sent: Tuesday, June 04, 2002 11:15 PM
> Subject: RE: [linux-lvm] EXT2 to EXT3 LVM volume on Redhat
> 
> 
> > > From: linux-lvm-admin@sistina.com 
> > > [mailto:linux-lvm-admin@sistina.com] On Behalf Of Aslak
> > >
> > > Hi again, and thanks for your quick reply!
> > >
> > > >----- Original Message -----
> > > >From: "Ben Lutgens" <blutgens@sistina.com>
> > [big snip]
> > > >Don't presume that because it's EXT3 that fscks are no longer 
> > > >necessary. Only thing the journal guarantees is that 
> your metadata 
> > > >won't become corrupt (i think journal=data mount option 
> fixes this
> > but
> > > >will affect performance and not neccessarily badly). If your
> > filesystem
> > > >has been shutdown cleanly many many times you could 
> still has some 
> > > >loss. A fsck should take care of that.
> >
> > Yup journal=data is fantastic; I wouldn't be without it
> > on the volume that holds the home directories!
> > I tend to allocate filesystems based on functionality;
> > tmp gets ext2 cos its fast,
> > places like /var/spool get XFS cos it can be grown
> > in a pinch.

Re: [linux-lvm] EXT2 to EXT3 LVM volume on Redhat

[Stephen Tweedie]

Hi,

On Thu, Jun 06, 2002 at 08:31:30AM +1200, Steve Wray <steve.wray@paradise.net.nz> wrote:

> /dev/system/home /home ext3 data=journal 1 2
> 
> Its the bomb. I have a hell of a lot of dynamic data
> in that /home so in event of a crash there was a big
> chance of corruption. Not Any More!!!!!
> 8-)

I'm not quite sure why people think that data=journal is any "safer"
than the default data=ordered mode.  In fact, data=ordered could well
be safer simply because the default mode is probably in use on more
systems, and so is better tested.  :-)

data=journal writes the data to the journal as well as the metadata,
but *both* ordered and data modes flush data to disk carefully as part
of their transaction commit.  If you create new files with the default
of data=ordered, there is still an absolute guarantee that a
transaction commit will show all the data safe on disk, and you will
never see stale data blocks show up on disk after a crash.

Only the looser "data=writeback" mode of ext3 relaxes this guarantee
and makes data writes independent of metadata writes, as they are for
most other filesystems.

Cheers,
 Stephen