Journalling for files is a concept similar to redo in the world of oracle. With JFS, you get the process called jfsCommit running, which "commits" buffer operations. Each filehandle operation like "flush" or "close" is a "commit". Basically, journalled FS guarantees that the data written down synchronously will really written down to the disk device(s). If you can do DIO, your data is a little bit safer. What a journalling FS protects you against is a huge data loss of blocks that were in the buffer cache. On 02/28/2004 07:27:38 AM, Nuno Souto wrote: > ----- Original Message ----- > From: "Jesse, Rich" <Rich.Jesse@xxxxxxxxxxxxxxxxx> > > > 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. > > A journaled file system (JFS) does NOT protect you from loss of data. > Common misconception. The function of journaling in a file system > is to recover file system internal STRUCTURES (used to be called i-nodes > in the Unix days) if they hadn't been flushed to disk on a crash. > It does NOT recover its data. It won't protect you from an incomplete > chained write on pre-allocated blocks, for example. For that, you need > the normal after image recovery of databases. > > A JFS basically stops you from having to wait for hours while the OS > starts a full "fsck": it's not needed (in theory) in a journaled file > system. > > > 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. > > If you are running a non-journaled f/s on the Oracle datafiles and ONLY > on the Oracle datafiles and you do NOT have other files in that file system, > unless you have a very strange database I can guarantee you will NEVER lose > data on a fsck. It's impossible. A fsck ONLY recovers the "i-nodes". > These do NOT change for a normal Oracle datafile. So, they can't need > recovery or be lost. > > Oracle datafiles are pre-allocated and of a final size already. They do not > shrink or expand or get deleted or re-created with anywhere near the > frequency Alter database datafile '/dir/myfile.dbf' autoextend on next 16384M maxsize unlimited; > needed to cause harm to "i-nodes" in a crash. > > > 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. > > I'd need to see proof of that. Like I said: it's all to do with the > type of usage. If you mix Oracle datafiles with other volatile OS files > in your f/s, then you MUST ensure against f/s loss using a JFS. > If you don't, there is nothing in Oracle's normal use of files in a f/s > that will cause a fsck to fail. Nothing. A fsck "patches" stuffed up > allocations of blocks. Oracle uses pre-allocated blocks. > Take away the root of the problem, you got no problem. > > > What FS benchmark site? Why is it flawed? Is there a "good" benchmark > > site? > > The Quest site with the Linux file system benchmarks. All done without a > single description of what block size was used for the f/s, which one > for the database, which parameters were used for the f/s configs, > no testing of the impact of different write sizes (redo logs versus > datafiles), > etcetc. Too many things wide open to be a reliable source for any > decisions. > > Cheers > Nuno Souto > in sunny Sydney, Australia > dbvision@xxxxxxxxxxxxxxx > > ---------------------------------------------------------------- > 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 > ----------------------------------------------------------------- > -- Mladen Gogala Oracle DBA ---------------------------------------------------------------- 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 -----------------------------------------------------------------