On Mon, Jan 30, 2012 at 7:46 PM, Dag Wieers <[log in to unmask]> wrote:
> On Mon, 30 Jan 2012, Yasha Karant wrote:
>
>> On 01/30/2012 03:35 PM, Dag Wieers wrote:
>>
>>>  I wonder:
>>>
>>>  - whether you were in fact using a journalling filesystem (because it
>>>  should even recover from power failure like that when it is journalled)
>>
>>
>> For the most part, for a number of reasons, we are sticking with ext2,
>> with -- in the case of my workstation -- fuse ntfs for MS Windows which is
>> required for particular unpleasantries.  We have not made a production
>> change to ext4, but are considering the transition.  We are attempting to
>> get detailed data on the reliability of the ext4 filesystem, how much
>> overhead (loss of data capacity) ext4 requires, and the performance change
>> (loss?) between ext2 and ext4.  Any detailed, preferably quantitative,
>> comparisons on production systems will be appreciated.
>
>
> I wonder why you chose ext2 over ext3. The cause of all your troubles is
> because you did not opt for the journaling filesystem. And ext3 is nowadays
> a lot more tested and a safer option than ext2. Ext4 does not have the same
> maturity/reliability as ext3, but it is getting there.

Begging to differ here: the cause is an unclean shutdown. *NO*
filesystem can protect against the state of a hard drive that hasn't
yet received information that is still paged out, lthough ext3 and
ext4 are much more likely to survive and be recoverable.

>>>  - what was mounted on /mnt/sysimage (as normally this is your
>>>  root-filesystem during installation, not during runtime)
>>
>>
>> I did a manual umount from the rescue running image, and verified with
>> mount that /mnt/sysimage was not mounted .  Nonetheless, when the production
>> system attempted to reboot, it reported that the /dev/sda5 was not cleanly
>> unmounted, and started automatic fsck.  This fsck failed, with the request
>> that I manually run fsck -- an operation I could not do as the root password
>> was not accepted, being truncated by the root password input procedure.
>
>
> Ok, I now see what you mean. It is rather confusing to refer as the
> filesystem having problems is /mnt/sysimage, while that is not the location
> where it normally is mounted. If you would have mentioned it was your root
> filesystem, that would have been more clear.

Dag, this is the default location that the rescue CD or media use, and
where the installer mounts the filesystems when doing installations.
It's very useful to be able to "chroot" into that environment to run
commands on the "local" system, and this is how the installer does
things as well for "after rpm is run" operations or '%post" operations
from a kickstart setup.

Normally, the partitions there are mounted read-only for precisely
such "rescue" operations. So it was clear to *me*, but I've done a
stack of kernel and hardware evaluation work where I had to deal with
just such situations. I tend to keep a PXE "rescue" setup around, as
well, for just such situations.

> BTW I am surprised you are not using LVM either. I find it very strange to
> see in this day and age a system still using mere partitions and ext2. This
> 2012, we left filesystem on partitions at least 2 major release (about 6
> years) ago :)

For many systems, especially virtualized systems, it's a waste of time
and of computational resources. It also makes accessing a virtualized
filesystem for system migration or recovery more awkward. Not that
this host was virtualized, but there are plenty of reasons to avoid
the unnecessary complexity and simply have a /boot, /, and swap space
if you need them. I've even had good success with only a / partition
in many virtualized systems.

>> Do the above comments clear the fog?
>
>
> A bit.
>
>
> --
> -- dag wieers, [log in to unmask], http://dag.wieers.com/
> -- dagit linux solutions, [log in to unmask], http://dagit.net/
>
> [Any errors in spelling, tact or fact are transmission errors]