Large SAN filesystems Linux boxes

[Brem Belguebli]

Hello,

We have some Linux (RHEL 4U5) machines running Oracle 10g databases with some SAN (XP12000 arrays) filesystems larger than a few hundreds of gigabytes.

I have 2 questions:

The badblocks reallocation is managed directly by the arrays, the question is how to disable the system badblocks mgmt when creating our VG's (on our HPUX boxes, we use something like -r N) ?

The second topic concerns the time fsck takes to check those large filesystems.

We have disabled the regular (both mount count and day count relative checks on our ext3 filesystems as they are journalized) but in case of a crash it can take up to 20 hours to check the whole thing.

Are there some workarounds to this ?
Thanks

[Matti_Kurkela]

To your first question: why do you assume Linux even _has_ a badblocks management system at the LVM level?
As far as I know, there is no such thing.

HP-UX LVM is older than Linux LVM. When Linux LVM was designed, both SCSI and IDE disks had had an internal badblock management system for quite a while. It was already an established practice to stop using any disk that had badblocks visible to the file system. (That means the disk's internal reserve of spare blocks is already exhausted, and the actual fault is already fairly severe and likely to get worse over time.)

It would make sense that the badblock management was left out of Linux LVM as an unnecessary duplication of functionality.


I don't know any real workarounds to your second question. Any workaround would mean accepting the chance that your filesystem has been corrupted by the crash, and risking bigger problems later.

I think you should be concentrating on the reason why your machines are crashing and trying to remove it.
Hardware failure? -> find the problem and fix it; if necessary, switch to more reliable hardware.
Power problems? -> If you don't already have an UPS, get it now.

MK

[Brem Belguebli]

Hello,

Ok about LVM.

What better hardware than HP do you recommend me ? ;-)
I haven't met yet the ideal hardware on which no problem occurs. Even our full RX8640 machines crash from time to time due to hardware issues (CPU problems mostly).

We had a similar issue on a DL585 (one of the machines hosting the large filesystems)and the machine crashed.

[skt_skt · Accepted solution]

check this my own thread for fsck time

https://forums12.itrc.hp.com/service/forums/questionanswer.do?threadId=1199633

[Brem Belguebli]

Hello,

In your fsck thread, you say
-----------------------------------------
With journal, after a crash, transactions will be check in the journal, as a database does. After a crash, fsck on a ext3 system only check the journal, you can force a full fsck, but is not required.
-----------------------------------------
Do you mean it (check the journal) is the default behavior of fsck when it will see the filesystem stated dirty or is there a FS option (that I don't see with tune2fs) to setup to force fsck to only check the journal ?

Regards

[Heironimus]

A journal replay is the default behavior.

[Brem Belguebli]

Thanks guys for your answers.