[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: nice mini-howto



On Oct 23, 2001  19:14 +0000, sayamindu dasgupta wrote:
> i am a newbie to this list and i don't know if this has been posted before
> i just noticed a nice mini-howto on ext2-ext3 conversion at
> http://www.symonds.net/~rajesh/howto/ext3/index.html
> i think that maybe a link can be added to this after the download section...

Some words to be added to the "why migrate to ext3" section:
(at the end of "Data Integrity:") ... the filesystem is the default.  (ADD)
"\nSince ext3 has the same on-disk format as ext2 it can use the very well
tested and reliable e2fsck to ensure filesystem integrity and recover from
errors, when this is needed."

(at the end of "Speed:") ...but is sometimes faster for certain database
operations (ADD) ", NFS, and synchronous MTA (mail server) operations".

(at the end of "Easy transition:") ...the advantages of ext3.  (ADD)  "It
is also possible to use an "ext3" filesystem with older kernels that only
understand ext2, as long as the filesystem has been cleanly unmounted or
if e2fsck (1.20+) is run on it."

In "Requirements" please replace "u" with "you".  Also, the latest version
of "util-linux" is NOT required unless you want to have "auto" in the
/etc/fstab entries for ext3 filesystems.

In "Upgrading Packages", you can usually also download up-to-date RPMs
from e2fsprogs.sourceforge.net.

In "5.4 Filesystem check intervals", _please_ don't suggest that everyone
disable the check intervals.  At most, remove the per-mount check interval
(tune2fs -c 0) and leave the time-based interval alone (or even a shorter
interval is good).  Otherwise, people will never notice if their kernel,
disk, cable, ram, etc is bad until too late.

Please add a section in #5 something along the lines of:

"Since an ext3 filesystem will not normally be checked at boot time, one
option for long-running systems is to use the LVM snapshot feature to create
a read-only snapshot of a filesystem and run a read-only e2fsck on the
snapshot to ensure that your filesystem has not been corrupted by bad RAM,
cables, disk drive, or kernel.

You need to have your filesystem on an LVM Logical Volume, and you need the
"LVM VFS Enhancement" patch applied for this to work properly (although it
may work without the VFS enhancement patch on non-busy filesystems).  Youa

For example, to run such a check on a Logical Volume (can be done at any
time while the system is running, even from a cron script).  This assumes
that you will not change more than 64MB of data in a single Logical Volume
during the course of the e2fsck, and that you have this much space free in
each volume group you want to test):

    # simple but stupid LV listing (hardcoded LV names to check)
    #for LV in /dev/vg00/lv1 /dev/vg00/lv2 /dev/vg01/lvA /dev/vg01/lvB; do
    # this assumes that all LVs have ext2/ext3 filesystems on them
    for LV in `lvscan | sed -n -e '/ACTIVE/s/[^\"]*\"//' -e 's/\".*//p'`; do
	SNAP=lvtempsnap
	SNAPDEV=`dirname $lv`/$SNAP
        lvcreate -L 80M -s -n $SNAP $LV
	[ $? -ne 0 ] && echo "**** WARNING **** unable to check $LV" && continue
        e2fsck -fn $SNAPDEV
        [ $? -ne 0 ] && echo "**** ERROR **** problem with filesystem on $LV"
        lvremove -f $SNAPDEV
	[ $? -ne 0 ] && echo "**** WARNING **** unable to remove $SNAP"
    done
" 

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]