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 [email protected] http://oss.oracle.com/mailman/listinfo/ocfs2-users
_______________________________________________ Ocfs2-users mailing list [email protected] http://oss.oracle.com/mailman/listinfo/ocfs2-users
