cwfs...

cwfs...

[Ethan Grammatikidis]

i've got a drive on usb while it's initialized, to be switched over to
esata for production. basically:

lahti% cwfs64x -cf /shr/usb/sdU8.0/fscache -n newcwfs 
config: service newcwfs
config: config /shr/usb/sdU8.0/fscache
config: filsys main c(/shr/usb/sdU8.0/fscache)(/shr/usb/sdU8.0/fsworm)
config: filsys dump o
config: filsys other (/shr/usb/sdU8.0/other)
config: noauth
auth is now disabled
config: ream main
config: ream other
config: end
current fs is "main"
cmd_users: cannot access /adm/users
63-bit newcwfs as of Mon Dec 12 11:45:39 2011
	last boot Fri Apr 13 06:12:50 2012
checktag pc=18f92 n(4) tag/path=Tnone/0; expected Tsuper/2
w"/shr/usb/sdU8.0/fsworm" block 2 WORM SUPER BLOCK READ FAILED
lahti% 

wot now?

Re: cwfs...

[cinap_lenrek]

looking at the source, it seems you get that error because
the superblock hasnt been written to the worm yet.

this only happens when you start with a blank worm partition.

the error here looks spooky, but i think its non critical in
that case. consinit just fires a touchsb command without
really caring for the result.

you might add the following code to the end of cwream()

	/* write superblock to worm */
	while(dumpblock(dev))
		;

--
cinap

backing up (was: cwfs...)

[Ethan Grammatikidis]

On Fri, 13 Apr 2012 12:55:20 +0200
cinap_lenrek@gmx.de wrote:

> looking at the source, it seems you get that error because
> the superblock hasnt been written to the worm yet.
> 
> this only happens when you start with a blank worm partition.
> 
> the error here looks spooky, but i think its non critical in
> that case. consinit just fires a touchsb command without
> really caring for the result.
> 
> you might add the following code to the end of cwream()
> 
> 	/* write superblock to worm */
> 	while(dumpblock(dev))
> 		;
> 
> --
> cinap

Thanks. I don't think I'm going to be able to test this, I've got
random dysfunction to worry about. The ethernet failures came back a
few hours after I unplugged the usb drive yesterday (which has been
perma-connected the last few weeks). On the next boot the machine's
keyboard stopped working after I connected with drawterm, and just now
I found connections on port 80 are timing out where they were fine
yesterday.

I'm going to go through with my upgrade and watch for errors after
that. I also want to back up to my linux machine daily but I'm not
entirely sure how. Copying files which exist in the latest dump dir but
not the previous one seems sensible. (Correct me if I'm wrong.) I'm not
sure what to put the files into at the Linux end as I want to preserve
history. I could use vac with p9p's venti I guess, or I could run cwfs
in a vm. (Or kfs in a vm. ;) I think I would prefer cwfs, any thoughts?

Re: backing up (was: cwfs...)

[cinap_lenrek]

i tested the dumpblock() change with cwfs and it works fine now.

we still have venti server in plan9front, so you might use that
instead of the p9p one.

a plan9 fs can't store symlinks and device nodes... so a full
backup isnt really possible.

maybe check in the unix toolbox for a incremental backup solution.

for the random malfunctions, you have to focus on one issue at a
time. they dont really look related to me. and you better resolve
these issues before storing important data on that machine or it
will be a desaster.

what version of plan9front are you using?

is this a usb keyboard? if you have cpu access, you could check
the state of the kbdfs process...

what ethernet card is it? (sorry to ask again, but you always disappear
after i gave you debug instructions and then i forget out that info...)

in any case, run memtest on the machine if it behaves wiredly.

maybe swap the network card?

--
cinap

Re: backing up (was: cwfs...)

[Ethan Grammatikidis]

On Sat, 14 Apr 2012 13:47:36 +0200
cinap_lenrek@gmx.de wrote:

> i tested the dumpblock() change with cwfs and it works fine now.

great

> 
> we still have venti server in plan9front, so you might use that
> instead of the p9p one.

to write to the linux box's disk?

> 
> a plan9 fs can't store symlinks and device nodes... so a full
> backup isnt really possible.

no, going the other way, a backup of the front box. it's the 9front box
that's being flakey.

> 
> maybe check in the unix toolbox for a incremental backup solution.
> 
> for the random malfunctions, you have to focus on one issue at a
> time. they dont really look related to me. and you better resolve
> these issues before storing important data on that machine or it
> will be a desaster.

if i don't store (relatively) important data on it i won't use it
enough to test it properly. :) hence the daily backups, and anything
really important would get sent to the linux box's disk anyway. reminds
me i want to back up /n/other too.

> 
> what version of plan9front are you using?

still old, hence getting on with the upgrade

> 
> is this a usb keyboard? if you have cpu access, you could check
> the state of the kbdfs process...

x61 built-in kb. i will do that if it happens again.

> 
> what ethernet card is it? (sorry to ask again, but you always disappear
> after i gave you debug instructions and then i forget out that info...)

x61 built-in.

if it wasn't built-in i wouldn't complain until i'd tried another card.
same with keyboard.

> 
> in any case, run memtest on the machine if it behaves wiredly.

good catch, going to do that now.

> 
> maybe swap the network card?
> 
> --
> cinap

Re: backing up (was: cwfs...)

[Ethan Grammatikidis]

On Sat, 14 Apr 2012 13:47:36 +0200
cinap_lenrek@gmx.de wrote:

> in any case, run memtest on the machine if it behaves wiredly.

memtest86 3.5b found no errors on 2 passes. i also ran a disk test that
i found in the bios and that found no errors. i was going to joke
"maybe the southbridge is going south," but then I saw this on
rebooting after memtest:

Cannot find south bridge PCI.255.31.7

i think that message has been present on every boot, and it appears to
have found the ethernet, usb, and cardbus bridge as usual.