hi,

in case of an unclean shutdown, my system takes pretty long time to boot. a lot of time is spent checking the harddrives. but i can see some other systems around me boot quite fast, even if not shutdown properly.

this is the hard disk info on my machine:

Filesystem Size Used Avail Use% Mounted on
/dev/hda2 5.3G 5.0G 31M 100% /
/dev/hda3 24G 19G 4.1G 82% /home
/dev/hda5 21G 15G 5.2G 74% /user1
/dev/hda6 20G 20G 3.3M 100% /user2
/dev/hdb1 13G 7.1G 5.7G 56% /user3
/dev/hdb2 13G 12G 1.0G 92% /user4
/dev/hdb3 9.8G 9.8G 0 100% /user5
none 121M 0 120M 0% /dev/shm

i am running Red Hat 8 with the default kernel.

is there anything that i can do about this?

thanks,
rpb

I would assume that you have setup these partitions as ext2.
For a quicker start after an 'unplanned' shutdown convert these to ext3.

from 'man tune2fs'
--------------
-j Add an ext3 journal to the filesystem. If the -J option is not specified, the default journal parame-
ters will be used to create an appropriately sized journal (given the size of the filesystem) stored
within the filesystem. Note that you must be using a kernel which has ext3 support in order to actu-
ally make use of the journal.

If this option is used to create a journal on a mounted filesystem, an immutable file, .journal, will
be created in the top-level directory of the filesystem, as it is the only safe way to create the jour-
nal inode while the filesystem is mounted. While the ext3 journal is visible, it is not safe to delete
it, or modify it while the filesystem is mounted; for this reason the file is marked immutable. While
checking unmounted filesystems, e2fsck(8) will automatically move .journal files to the invisible,
reserved journal inode. For all filesystems except for the root filesystem, this should happen auto-
matically and naturally during the next reboot cycle. Since the root filesystem is mounted read-only,
e2fsck(8) must be run from a rescue floppy in order to effect this transition.

On some distributions, such as Debian, if an initial ramdisk is used, the initrd scripts will automati-
cally convert an ext2 root filesystem to ext3 if the /etc/fstab file specifies the ext3 filesystem for
the root filesystem in order to avoid requiring the use of a rescue floppy to add an ext3 journal to
the root filesystem.

Not an answer this - but your / partition is full, 31M left.
This will soon give you problems, I suggest you try to free some space.

ok guys..

thanks for the reply..

will try it ..

thanks,
rpb

hello,

i'm planning to convert from ext2 to ext3. but i have a few questions:

1) what if the power fails during the conversion process? i have 3 partitions 13G, 13G and 9G each and cannot afford the loss of data at any cost. so is there anyone who can assure me the safety of my data during the converson process?
2) does the process require a minimum amount of free space?

if someone knows the answers, kindly reply asap.

TIA,
rpb

So why don't you have a UPS?

i do have a UPS !! but no system is perfect...what if something goes wrong?

so whats the answer to my question now?

What, so you're paranoid enough to worry about power loss to a UPS-powered computer, but not paranoid enough to have backups of everything so it doesn't matter?

If your luck is so bad that you suffer a simultaneous power cut and UPS failure, then it's probably bad enough that you'll loose all your data as well.

Simply put: No. No process is perfect: If you need an absolute gaurantee that changing a filesystem won't loose your files, there's only one way to do it: Back everything up first.

I have a 40GB USB hard drive that fulfills that role perfectly. I'd recommend you get something similar. Back your data up, THEN change the filesystem.

Realistically, I wouldn't even consider the risk of loosing power on a computer connected to a UPS. However, I also wouldn't even consider tampering with a filesystem until I'd backed up all the data.

I can't imagine anyone giving you that kind of assurance.
That being said, AFAIK, ext3 is pretty much identical to ext2 apart from the journal,
so I wouldn't think it was a case of 'converting' anything, just the building of the journal itself.
eg. I can mount an ext3 partition as ext2 ... it just won't have journalling enabled.
From that point of view, if the 'conversion' was stopped by power failure, I'd be
surprised if you'd lose anything from the process itself (ie. user data), but wouldn't
be surprised if a few system files were corrupted (unless you were sensible and used
a livecd to do the job ) seeing as the system is live and writing to the disk.

Yes the journal takes up a small amount of space ... no I don't know how much.

ps. there is such a thing as 'healthy paranoia'

well guys,

thanks a lot for your responses...

ever heard of "focusing on problem" versus "focusing on solution"..? my problem was that it was taking me pretty long time to boot in case of power failures, apparently becoz i had 3 ext2 partitions...i think i was doing the latter; focusing on one of the possible solutions..:-)
now what i do is i comment these partitions in /etc/fstab and unmount them for time being...it ouwldn't be detected during boot and so that solves the problem !! mistake was in my part...from my posting i guess i was creating an impression that all my partitions were ext2...but the thing is that i have my root and home filesystems as ext3. some huge segments with a lot of data ( important; not used for time being ) is ext2. so i can easily keep from mounting them !!

dont have to do ext3 for the time being..!!

happy LQing..!!
rpb

You might want to try adding a 'noauto' option to each of the entries you don't want to automount,
instead of commenting them.

This will enable you to issue
#mount /mountpoint
rather than
#mount /device /mountpoint