On Wed, Sep 09, 2009 at 12:13:53PM +0200, Christoph Lechner wrote: > Lars Ellenberg wrote: > >> The question was if you would recommend a change to ext3. > > > > If you do not need concurrent access, yes, I'd strongly recommend to > > get rid of the cluster file system. > > > > As long as you don't export via NFS or similar, > > I think the downtime can be reduced to about a minute. > > Don't think that is "long" for such a task. > > How can one achieve that? My naive approach would have been to create a > new ext3 on a seperate partition and copy it all. > > How can one reduce the downtime to about a minute?
Yes, you need a newly created ext3. Either on a separate partition, or, if you want to degrade your cluster for the transition time, you can re-use the DRBD on one of the nodes (disconnecting them on purpose, letting them diverge). services still running fine on the the OCFS2 data. rsync (with --bwlimit to reduce impact). rsync again. Start of downtime. stop services. rsync again. start services on the ext3 data. End of downtime. If you chose to re-use the drbd on one of the nodes, you now can let it do its full sync. My assumtion is, if you have enough ram to hold the inodes in cache, the inner incremental rsync should be done in minimum time. Obviously all inode information will change. That is why I mentioned NFS: all clients depending on inode information would need to be unmounted/remounted. Does that make sense? -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
