EXT2 to EXT3 LVM volume on Redhat
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
[email protected]
Quoted 3 lines · Aslak Sommerfelt Skretting
As far as i can understand a simple:
tune2fs -j
/dev/storage/space
Yup. I've done this many times with no problems.
Quoted 8 lines
would create a new journal file, and convert the filesystem to ext3. and a:
tune2fs -i 0
/dev/storage/spacewould 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.
Quoted 1 line
and then everything would be ok? or is there more that need to be done?
take backups.
take backups.
take backups.
take backups.
:-)
Quoted 3 lines
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 ;-)
Signature · 6 lines
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?"
Hi again, and thanks for your quick reply!
Quoted 11 lines
----- Original Message -----
From: "Ben Lutgens" <[email protected]>
To: <[email protected]>
Sent: Tuesday, June 04, 2002 10:31 PM
Subject: Re: [linux-lvm] EXT2 to EXT3 LVM volume on RedhatQuoted 3 lines
As far as i can understand a simple:
tune2fs -j
/dev/storage/spaceYup. I've done this many times with no problems.
Good, odds are in my favour :)
Quoted 2 lines
Quoted 2 lines
would create a new journal file, and convert the filesystem to ext3. and
a:
Quoted 4 lines
Quoted 4 lines
tune2fs -i 0
/dev/storage/spacewould disable the fsck's that occur now and then (and takes an insane
amount
Quoted 9 lines
Quoted 2 lines
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?
Quoted 7 lines
Quoted 2 lines
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.
Quoted 4 lines
:-)
Quoted 1 line
Quoted 8 lines
Quoted 2 lines
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 :)
Quoted 8 lines
--
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
[email protected]
Quoted 7 lines
From: [email protected] [mailto:[email protected]] On Behalf Of Aslak
Hi again, and thanks for your quick reply!
Quoted 2 lines
----- Original Message -----
From: "Ben Lutgens" <[email protected]>
[big snip]
Quoted 3 lines
Quoted 3 lines
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
Quoted 1 line
Quoted 1 line
will affect performance and not neccessarily badly). If your
filesystem
Quoted 2 lines
Quoted 2 lines
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.
This journal=data you talk about, is this an option to be used with the 'mount' command?
----- Original Message -----
From: "Steve Wray" <[email protected]>
To: <[email protected]>
Sent: Tuesday, June 04, 2002 11:15 PM
Subject: RE: [linux-lvm] EXT2 to EXT3 LVM volume on Redhat
Quoted 34 lines
Quoted 7 lines
From: [email protected] [mailto:[email protected]] On Behalf Of Aslak
Hi again, and thanks for your quick reply!
Quoted 2 lines
----- Original Message -----
From: "Ben Lutgens" <[email protected]>[big snip]
Quoted 3 lines
Quoted 3 lines
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
Quoted 1 line
Quoted 1 line
will affect performance and not neccessarily badly). If your
filesystem
Quoted 2 lines
Quoted 2 lines
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/spoolget XFS cos it can be grown in a pinch._______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
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-)
Quoted 39 lines
[mailto:[email protected]] 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" <[email protected]>
To: <[email protected]>
Sent: Tuesday, June 04, 2002 11:15 PM
Subject: RE: [linux-lvm] EXT2 to EXT3 LVM volume on RedhatQuoted 10 lines
Quoted 7 lines
From: [email protected] [mailto:[email protected]] On Behalf Of Aslak
Hi again, and thanks for your quick reply!
Quoted 2 lines
----- Original Message -----
From: "Ben Lutgens" <[email protected]>[big snip]
Quoted 2 lines
Quoted 2 lines
Don't presume that because it's EXT3 that fscks are no longer necessary. Only thing the journal guarantees is that
your metadata
Quoted 1 line
Quoted 1 line
Quoted 1 line
won't become corrupt (i think journal=data mount option
fixes this
Quoted 4 lines
but
Quoted 1 line
Quoted 1 line
will affect performance and not neccessarily badly). If your
filesystem
Quoted 1 line
Quoted 1 line
has been shutdown cleanly many many times you could
still has some
Quoted 8 lines
Quoted 1 line
Quoted 1 line
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/spoolget XFS cos it can be grown in a pinch.
Hi,
Quoted 6 lines · Steve Wray
/dev/system/home/home ext3 data=journal 1 2Its 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
Hi, Aslak!
Aslak Sommerfelt Skretting ([email protected]) wrote 51 lines:
Quoted 3 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