Re: Moving db to linux

  • From: Mladen Gogala <mladen@xxxxxxxxxxxxxxx>
  • To: oracle-l@xxxxxxxxxxxxx
  • Date: Fri, 27 Feb 2004 11:35:02 -0500

Yes, there is a good FS benchmark site. Take a load of this:
http://fsbench.netnation.com/

On 02/27/2004 11:21:43 AM, "Jesse, Rich" wrote:
> I have to question using a non-journaled FS like ext2 on a production box,
> unless downtime and loss of data is not a factor.  The time to fsck several
> GB after a crash (or even after a simple reboot, depending on FS settings)
> can take hours.  And that's provided there isn't a problem with the FS.  If
> there is, the most likely avenue of recovery is to go back to tape and roll
> forward.  And if you're archived logs were ext2 as well, you may be staring
> at yourself in the mirror to see your boss' boot print on your backside.
> 
> What FS benchmark site?  Why is it flawed?  Is there a "good" benchmark
> site?
> 
> Rich
> 
> Rich Jesse                        System/Database Administrator
> rich.jesse@xxxxxxxxxxxxxxxxx      QuadTech, Sussex, WI USA
> 
> 
> > -----Original Message-----
> > From: Nuno Souto [mailto:dbvision@xxxxxxxxxxxxxxx]
> > Sent: Friday, February 27, 2004 7:21 AM
> > To: oracle-l@xxxxxxxxxxxxx
> > Subject: Re: Moving db to linux
> > 
> > 
> > ----- Original Message ----- 
> > From: "Jesse, Rich" <Rich.Jesse@xxxxxxxxxxxxxxxxx>
> > 
> > > I haven't yet, but I'm getting the feeling that ext3 is not 
> > preferred.  If
> > > not, then what?  I've already had ext2 trash my entire "/", 
> > even though I
> > > was doing a mke2fs on a separate RAID MP, so that's not an option.
> > >
> > > JFS?  XFS?  FAT?  WHY one over the other?
> > >
> > 
> > This is one of those situations I feel you should consider the "need"
> > versus the "standard".  There is no point whatsoever with Linux in
> > "standardising" on a file system.  It is counter to the 
> > ENTIRE philosophy
> > of Unix and Linux.
> > 
> > First of all, consider the requirements.
> > 
> > Condition:
> > "/" (and other "system" file systems) are where you load the 
> > system software
> > and where you'll store mostly many short files of either text 
> > or binary
> > (compiled code) data.  It needs to cope well with volatility as the OS
> > dynamically allocates and drops files and new space to existing files.
> > Ie, the file system internal structures CHANGE, so you need 
> > journaling to
> > avoid errors on sudden system stoppage.
> > 
> > Solution:
> > Therefore, you need to protect yourself using at the very least a
> > journalised
> > file system.  ext3, JFS, Reiser (and PLEASE nobody mention 
> > the f/s benchmark
> > site,I am FULLY aware how wrong it is!).  Chose one geared 
> > for fast delivery
> > on
> > small to medium sized files.  reiserfs is a good choice, so is JFS.
> > 
> > Condition:
> > With the Oracle data and assuming you want to use file 
> > systems to store
> > the datafiles, what you have is VERY LARGE files that are not 
> > often created,
> > dropped or added to IN SIZE.  Which means the file system structures
> > themselves do NOT need to be journalised, they hardly ever change.
> > Note: I said the file system internal structures, NOT your data.
> > Yes, there is a HUGE difference!
> > 
> > Solution:
> > So, for your data either use raw or a simple, no frills file system
> > with sufficient features to give you performance: noatime, asynch I/O
> > if you can find it, otherwise at the very least direct I/O.  ext2
> > will do the job, so will ext3 with journal turned off, etcetc.  Do NOT
> > use a file system geared for small file server, like 
> > reiserfs, FAT, etcetc.
> > 
> > And that's it in a nutshell.  Do NOT look for a one-size-fits-all
> > file system:  there is NO such animal.
> > 
> > Cheers
> > Nuno Souto
> > 
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
> 
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: