D&C Lug - Home Page
Devon & Cornwall Linux Users' Group

[ Date Index ][ Thread Index ]
[ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG] raid 1 and journalled filesystems



from bill@xxxxxxxx
Use a hardware RAID card with cache will reduce the overhead to virtually nothing as  writes take place during idle times from cache. Reads however on good RAID cards will be quicker as they can calculate which head is nearest the data. RAID 5 OK but serios degradation will take place during a failure. Raid 1 will not degrade the same way  in the event of failure.
However at least 50% of our failures are of the RAID card itself or the controller in software RAID. If you are concerned about this the only solution is RAID 10 with each  pack on a separate controller or at least a different channel on the same controller.

Simon Waters wrote:
Alex Charrett wrote:
Is a journalled filesystem necessary on a mirror, or indeed as it's a
software mirror will the combination of the two create unnecessary
overhead on the machine?

Mirroring in most Unix systems (you'll have to check Linux) is
pretty low overhead (assuming(!!!!) you keep your I/O channels
free by using seperate I/O channels to each disk in a pair -
thus your system should survive minor issues like IDE bus
failure).

It just schedules two writes for each write - fairly painless
when done in software, even more painless when done in hardware
(although that makes I/O channel redundancy fun!).

File systems integrity is more about power failure or similar
than disk failure (heck if you don't mirror and the disk fails,
file system type is largely irrelevant).

So chose your file system based on what it is doing, not what
the disks are (assuming you don't use stupid disk types for
things - hey I see a lot of Oracle redo logs on RAID 5 - I see
quite a few systems using RAID-5 for everything - I think some
people think it gets better as the number goes up - well t hey'll
be all right at 10 ;-)

Read the Oracle SAME documents if you feel tempted to use RAID 5
anywhere.

SAME - Striping And Mirroring Everywhere.

RAID 5 is for archives ;-) I have some Oracle database files on
RAID-5 somewhere, but hey the box would have been SAME'd if I'd
done the install.

I've heard Pete mention a few times that ext3 has given him major
performance issues when doing database work, but it is of course
possible to store the db files on a non journalled slice and the rest on
journalled.

I'd guess journalling things like /usr is pretty pointless because it
doesn't change too often but perhaps it is good on /var and /home, but
still not sure how this will impact system performance.

Journalling on /usr, of course, whilst you write to it less
often if it goes "tits up" whilst you are writing to it, well it
can take a long time to recover compared to just restoring a
database.

I have a 20GB Oracle database stashed away on a machine, it
takes 3 hours to recover the database from tape, 8 to recover
the OS and database, I don't want /usr to bite the dust when I'm
patching it!

Any suggestions/experiences?

Journal everything apart from database files that are doing
their own journalling!

Journal everything that can be, has been HP's default for years,
originally the kernel had to be on an unjournalled system, but
hell you don't want to lose stuff when rebuilding a kernel, so
they fixed the loader to boot from a journalled file system.

Follow the database provider, and file system provider advice on
configuring database files. If possible try and figure out
exactly the paths a database write takes though the system in
terms of disk writes, blocking and unblocking.

The Veritas file systems support lazy journalling models
suitable for database files, I believe Reiser has something
similar, and probably ext3, most of these things (i.e. making
decisions on when to do what) are fairly easy to implement
compared to writing a journaled file system in the first place.

Big issue can be fsck time for non-journalled file systems -
spending 10 to 15 minutes runnings fsck on a reboot is not fun,
especially if it then says "rerun fsck manually", and you have
another 10 to 15 minutes before the users go away.

--
The Mailing List for the Devon & Cornwall LUG
Mail majordomo@xxxxxxxxxxxx with "unsubscribe list" in the
message body to unsubscribe.

intY has scanned this email for all known viruses (www.inty.com)





***** YLEM DISCLAIMER  *****

To obtain a copy of Ylem's email disclaimer ring 01398 323146
intY has scanned this email for all known viruses (www.inty.com)

Lynx friendly