I can't disagree enough with #4. Most of our customers who are the most successful with RAC do so with a mixed configuration of OCFS2 and ASM. OCFS2 is used for spfiles, password files, an archive log dest, while the ASM instance holds all of the data. This neatly gets around the limitations of OCFS from a volume management perspective, gets rid of the need for raw devices to use for the spfile, and can help mitigate "data black box" concerns about ASM, as you'll have an additional destination for your archive logs that is not ASM for backups, recovery, etc. As far as #5, OCFS2 works with 2.6 kernels... Thanks, Matt -- Matthew Zito Chief Scientist GridApp Systems P: 646-452-4090 mzito@xxxxxxxxxxx http://www.gridapp.com -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx on behalf of Torsten Rosenwald Sent: Wed 8/15/2007 4:45 AM To: lizzpenaorclgrp@xxxxxxxxx Cc: oracle-l@xxxxxxxxxxxxx Subject: AW: Linux RAC using OCFS2 - inital installation questions Hi Laura, reading the docs is a very good starting point...;-) do not forget to download the patches (10.2.0.3.0) 1> it depends on what you are going to use for the 'file system' (ASM or RAC) 2> No, you should not. establish user equivalence and follow the docs. 3> What you mean is the cluster verification utility (cluvfy.sh), you should use it. 4> This is the point you should decide which way you want to go: the ASM or the OCFS2 way, but: do not mix it (due to complexity reasons) 5> OCFS only works witth 2.4 kernels, so this is no choice here, use OCFS2 6> There is no such thing as an ASM flashback recovery area. Maybe there only has been a misunderstanding;-) You may store your FRA in ASM, but ASM does not provide one by itself, ok? Archive logging provides a roll-forward-mechanism, flashback a rollback mechanism. those are very different things. hth, Torsten.