ref: 9233f5e9898ff7430864404e122d9d5916f6252c
parent: d3f82d64da6f68675651b8271fb126fb502c0125
author: kvik <[email protected]>
date: Thu Dec 3 11:04:08 EST 2020
migrating-cwfs: add entry (thanks Alex Musolino)
--- /dev/null
+++ b/migrating-cwfs.md
@@ -1,0 +1,145 @@
+# Migrating CWFS
+
+From time to time one may wish to move a CWFS instance from one device
+to another. Perhaps the old device is full or faulty. Perhaps you'd
+just like to make a backup. In any case, the process is fairly simple.
+
+## Prepare new device
+
+After installing the new drive and powering up the machine, the first
+thing to do is identify the new device. The `#S` device
+indicates that the new device has been recognised.
+
+ cpu% ls '#S'
+ '#S/sdD0'
+ '#S/sdD1'
+ '#S/sdctl'
+ cpu% cat '#S/sdD0/ctl'
+ inquiry KINGSTON SA400S37240G
+ config 0040 capabilities 2F00 dma 00550020 dmactl 00550020 rwm 1 rwmctl 0 lba48always off
+ model KINGSTON SA400S37240G
+ serial 50026B768422720C
+ firm SBFKJ4.3
+ feat lba llba smart power nop ata8
+ geometry 468862128 512
+ alignment 512 0
+ missirq 0
+ sloop 0
+ irq 18977 30
+ bsy 0 0
+ nildrive 6
+ part data 0 468862128
+ cpu%
+
+Next, we prepare the MBR and DOS partition table with
+`disk/mbr` and `disk/fdisk`:
+
+ cpu% disk/mbr -m /386/mbr '#S/sdD0/data'
+ cpu% disk/fdisk -w -a '#S/sdD0/data'
+ cpu% cat '#S/sdD0/ctl'
+ inquiry KINGSTON SA400S37240G
+ config 0040 capabilities 2F00 dma 00550020 dmactl 00550020 rwm 1 rwmctl 0 lba48always off
+ model KINGSTON SA400S37240G
+ serial 50026B768422720C
+ firm SBFKJ4.3
+ feat lba llba smart power nop ata8
+ geometry 468862128 512
+ alignment 512 0
+ missirq 0
+ sloop 0
+ irq 20034 55
+ bsy 0 0
+ nildrive 6
+ part data 0 468862128
+ part plan9 63 468862128
+ cpu%
+
+Now we can set up the plan9 partition table. I've chosen to elide the
+'other' partition this time around as I've never used it in the entire
+6 years that I've been using the previous filesystem.
+
+ cpu% disk/prep -w -a 9fat -a nvram -a fscache -a fsworm '#S/sdD0/plan9'
+ no plan9 partition table found
+ 9fat 204800
+ nvram 1
+ fscache 78109544
+ fsworm 390547720
+ cpu%
+
+## Copy old WORM
+
+Disable the background dump service and trigger a final dump of
+the old file system:
+
+ cpu% echo startdump 0 >>/srv/cwfs.cmd
+ cpu% echo dump >>/srv/cwfs.cmd
+
+There's no point copying the entire WORM partition so let's work out
+how much of it needs to be copied using the `statw` command:
+
+ cpu% con -C /srv/cwfs.cmd
+ statw
+ cwstats main
+ filesys main
+ maddr = 3
+ msize = 5147
+ caddr = 518
+ csize = 694845
+ sbaddr = 1668338
+ craddr = 1697494 1697494
+ roaddr = 1697497 1697497
+ fsize = 1697599 1697599 0+48%
+ slast = 1668081
+ snext = 1697498
+ wmax = 1697497 0+48%
+ wsize = 3484185 1+ 0%
+ 223247 none
+ 8903 dirty
+ 0 dump
+ 461561 read
+ 1134 write
+ 0 dump1
+ cache 5% full
+
+So we need only copy `fsize` 16K blocks. We can use
+`dd(1)` to do so, but **please**, double and triple check the
+order of your arguments before running this command!
+
+ cpu% dd -if '#S/sdD1/fsworm' -of '#S/sdD0/fsworm' -bs 16k -count 1697599
+ cpu%
+
+This will likely take quite some time. In the example above, copying
+1697599*16K ≈ 25G took around 10 minutes or so.
+
+## Bring up new FS
+
+ cpu% bind -a '#S' /dev
+ cpu% cwfs64x -n newcwfs -f /dev/sdD0/fscache -C -c
+ config: service cwfs
+ config: config /dev/sdD0/fscache
+ config: filsys main c(/dev/sdD0/fscache)(/dev/sdD0/fsworm)
+ config: filsys dump o
+ config: recover main
+ config: end
+ checktag pc=20eb0f n(3) tag/path=Tnone/0; expected Tsuper/2
+ current fs is "main"
+ 11 uids read, 7 groups used
+ 63-bit cwfs as of Mon Nov 9 20:51:45 2020
+ last boot Sat Nov 28 14:34:23 2020
+ cpu%
+
+You can now mount the new filesystem:
+
+ cpu% mount /srv/newcwfs /n/newroot
+ cpu% mount /srv/newcwfs /n/newdump dump
+ cpu%
+
+## Copy 9fat and nvram
+
+The last thing to do is to copy the 9fat and nvram partitions from
+your old disk to the new one. This is trivial:
+
+ cpu% cp '#S/sdD1/9fat' '#S/sdD1/nvram' '#S/sdD0'
+ cpu%
+
+You should now be able reboot from the new disk.