On Fri, Aug 20, 2010 at 10:17 AM, Simon Wilkinson <s...@inf.ed.ac.uk> wrote: > > On 20 Aug 2010, at 15:05, Gémes Géza wrote: > >> We currently have a small cell (2 db and file-servers >> (1.4.7.dfsg1-6+lenny1), ~50 volumes). But plan to move the user home >> dirs to afs resulting in >1000 volumes. Being afraid of the fs based >> startup times we decided to move to a 1.5 based dafs prior to complete >> the data migration to afs. > > If you have sufficient hardware, I would urge you to perform your migration > by using AFS's tools, rather than playing fast and loose with where volumes > are mounted. So, bring up some dafs fileservers, and use vos move to migrate > volumes from the 1.4 servers to the 1.5 ones. This has the advantage that > you've got a very simple backout plan if things go wrong for any reason, as > well as allowing you to perform a staged migration without any downtime. > >> The data is on a Coraid SAN, so it will be >> simply unmounted from the old fileservers, and mounted to the new ones, >> but what operations would we need to perform on the ubik data? > > If you do want to go down this route, you will need to update the VLDB > location for every volume that has changed fileservers. vos syncvldb and vos > syncserv should do this for you - but there will be a period of outage for > all of your clients. >
I agree with Simon: using vos move is much better, as it gives you a staged migration (and backout) plan, increases availability of data, all without adding the risks involved with re-attaching disks to a different system. Steven _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
