shithub: docs.9front.org

Download patch

ref: 9233f5e9898ff7430864404e122d9d5916f6252c
parent: d3f82d64da6f68675651b8271fb126fb502c0125
author: kvik <kvik@a-b.xyz>
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.