I am working currently on cloning on a regular basis our production OCFS2 volumes to our test environment. For the database (Oracle 10G R2 RAC) we put it into backup mode, then execute a Snapclone on our 3Par SAN. Then we use RemoteCopy and SnapClone to our development 3Par SAN. To recover the OCFS2 volume I got through the following steps: Stop database umount /export/<volume name> Log into SAN to refresh Snapclone fsck.ocfs -y /dev/mapper/<volume name> mount /export/<volume name> umount /export/<volume name> tunefs.ocfs -U /dev/mapper/<volume name> tunefs.ocfs -L /export/<volume name> /dev/mapper/<volume name> mount /export/<volume name> Go through steps to recover and rename database Start database This seems to work, although I am curiously why I have to mount/umount the volume in between fsck and tunefs. The fsck obviously will go through and recover the journal but unless I mount/umount the volume once, tunefs will come back with dirty file system. Are there any other steps I should be doing or does this sequence look ok? Regards, Ulf. --------------------------------------------------------------------- ATC-Onlane Inc., T: 650-532-6382, F: 650-532-6441 4600 Bohannon Drive, Suite 100, Menlo Park, CA 94025 ---------------------------------------------------------------------
While fsck.ocfs2 replays the journals, it does not clean the orphan dir. We leave it dirty so that the mount thread can clean it. I guess we can make tunefs smarter in that it can read the journals and see whether they have been replayed or not instead of relying on the journal dirty flag. We are being cautious... or just being plain lazy - take your pick. File an enhancement if you feel this change is worth having. Sunil Ulf Zimmermann wrote:> I am working currently on cloning on a regular basis our production > OCFS2 volumes to our test environment. For the database (Oracle 10G R2 > RAC) we put it into backup mode, then execute a Snapclone on our 3Par > SAN. Then we use RemoteCopy and SnapClone to our development 3Par SAN. > > To recover the OCFS2 volume I got through the following steps: > > Stop database > umount /export/<volume name> > Log into SAN to refresh Snapclone > fsck.ocfs -y /dev/mapper/<volume name> > mount /export/<volume name> > umount /export/<volume name> > tunefs.ocfs -U /dev/mapper/<volume name> > tunefs.ocfs -L /export/<volume name> /dev/mapper/<volume name> > mount /export/<volume name> > Go through steps to recover and rename database > Start database > > This seems to work, although I am curiously why I have to mount/umount > the volume in between fsck and tunefs. The fsck obviously will go > through and recover the journal but unless I mount/umount the volume > once, tunefs will come back with dirty file system. > > Are there any other steps I should be doing or does this sequence look > ok? > > Regards, Ulf. > > --------------------------------------------------------------------- > ATC-Onlane Inc., T: 650-532-6382, F: 650-532-6441 > 4600 Bohannon Drive, Suite 100, Menlo Park, CA 94025 > --------------------------------------------------------------------- > > > _______________________________________________ > Ocfs2-users mailing list > Ocfs2-users@oss.oracle.com > http://oss.oracle.com/mailman/listinfo/ocfs2-users >
Ok, so my fsck replays the journal, but even if I run fsck again after that, I would normally expect it to clear the dirty flag. But that is out of experience with other file systems. As long my action sequence is ok, I do not care either way, but I was curious about it.> -----Original Message----- > From: Sunil Mushran [mailto:Sunil.Mushran@oracle.com] > Sent: Monday, February 25, 2008 15:49 > To: Ulf Zimmermann > Cc: ocfs2-users@oss.oracle.com > Subject: Re: [Ocfs2-users] OCFS2 and Cloning > > While fsck.ocfs2 replays the journals, it does not clean the orphan > dir. We leave it dirty so that the mount thread can clean it. > > I guess we can make tunefs smarter in that it can read the journals > and see whether they have been replayed or not instead of relying > on the journal dirty flag. We are being cautious... or just being > plain lazy - take your pick. > > File an enhancement if you feel this change is worth having. > > Sunil > > Ulf Zimmermann wrote: > > I am working currently on cloning on a regular basis our production > > OCFS2 volumes to our test environment. For the database (Oracle 10GR2> > RAC) we put it into backup mode, then execute a Snapclone on our3Par> > SAN. Then we use RemoteCopy and SnapClone to our development 3ParSAN.> > > > To recover the OCFS2 volume I got through the following steps: > > > > Stop database > > umount /export/<volume name> > > Log into SAN to refresh Snapclone > > fsck.ocfs -y /dev/mapper/<volume name> > > mount /export/<volume name> > > umount /export/<volume name> > > tunefs.ocfs -U /dev/mapper/<volume name> > > tunefs.ocfs -L /export/<volume name> /dev/mapper/<volume name> > > mount /export/<volume name> > > Go through steps to recover and rename database > > Start database > > > > This seems to work, although I am curiously why I have tomount/umount> > the volume in between fsck and tunefs. The fsck obviously will go > > through and recover the journal but unless I mount/umount the volume > > once, tunefs will come back with dirty file system. > > > > Are there any other steps I should be doing or does this sequencelook> > ok? > > > > Regards, Ulf. > > > >---------------------------------------------------------------------> > ATC-Onlane Inc., T: 650-532-6382, F: 650-532-6441 > > 4600 Bohannon Drive, Suite 100, Menlo Park, CA 94025 > >---------------------------------------------------------------------> > > > > > _______________________________________________ > > Ocfs2-users mailing list > > Ocfs2-users@oss.oracle.com > > http://oss.oracle.com/mailman/listinfo/ocfs2-users > >