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_at_quadtechworld.com QuadTech, Sussex, WI USA
>
>
> > -----Original Message-----
> > From: Nuno Souto [mailto:dbvision_at_optusnet.com.au]
> > Sent: Friday, February 27, 2004 7:21 AM
> > To: oracle-l_at_freelists.org
> > Subject: Re: Moving db to linux
> >
> >
> > ----- Original Message -----
> > From: "Jesse, Rich" <Rich.Jesse_at_quadtechworld.com>
> >
> > > 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_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://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_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Received on Fri Feb 27 2004 - 10:32:38 CST
