[9fans] fossil shutdown

[9fans] fossil shutdown

[fgergo]

On 9/22/05, David Leimbach <leimy2k@gmail.com> wrote:
> Oftentimes the mouse pointer will go ape-shit and I'll
> have to drawterm in to shutdown fossil nicely and reboot.
Why do you need to shutdown fossil nicely?

Re: [9fans] fossil shutdown

[David Leimbach]

On 9/22/05, fgergo@gmail.com <fgergo@gmail.com> wrote:
> On 9/22/05, David Leimbach <leimy2k@gmail.com> wrote:
> > Oftentimes the mouse pointer will go ape-shit and I'll
> > have to drawterm in to shutdown fossil nicely and reboot.
> Why do you need to shutdown fossil nicely?
>
Because I have neither the time nor the patience to fight with venti. 
If the CD based installer worked on my machine at all, it'd be a lot
easier.   But since everything I do on Plan 9 is really just for kicks
I don't care that much if it all gets blown away now and again.

If you've ever tried to venti format a 20GB disk you'd know why it
sucks to deal with.  I don't have 24 hours to wait for it to finish as
this is also my main linux box for my day job.

And yes, I've lost data on fossil before.  So I take some precautions.

Dave

Re: [9fans] fossil shutdown

[Charles Forsyth]

> If you've ever tried to venti format a 20GB disk you'd know why it
> sucks to deal with.  I don't have 24 hours to wait for it to finish as
> this is also my main linux box for my day job.

perhaps you need

echo dma on >/dev/sdXX/ctl
echo rwm on >/dev/sdXX/ctl

i'm fairly sure it didn't take anything like that long when i set up my
32Gb arenas

Re: [9fans] fossil shutdown

[David Leimbach]

On 9/22/05, Charles Forsyth <forsyth@terzarima.net> wrote:
> > If you've ever tried to venti format a 20GB disk you'd know why it
> > sucks to deal with.  I don't have 24 hours to wait for it to finish as
> > this is also my main linux box for my day job.
>
> perhaps you need
>
> echo dma on >/dev/sdXX/ctl
echo dma on >/dev/sdC1/ctl gives:
disabling dma: not on a busmastering controller

I assume this is motherboard chipset support biting me again.  DMA
works fine in other OSes.

> echo rwm on >/dev/sdXX/ctl
this didn't produce a message but I've no idea if it's working either.

>
> i'm fairly sure it didn't take anything like that long when i set up my
> 32Gb arenas
>
>

Nforce2 is the bane of my plan 9 experience.

Re: [9fans] fossil shutdown

[Thomas Miller]

Way back on September 22, 2005 Charles Forsyth <forsyth@terzarima.net> 
wrote:

>
> perhaps you need
>
> echo dma on >/dev/sdXX/ctl
> echo rwm on >/dev/sdXX/ctl
>

Inspired, I tried this, and I got an improvement (decrease)
in time taken to copy files to a new filename of at least
an order of magnitude.  The really interesting part of the
experiment was, however, that my computer subsequently 
failed to boot from the hard disk.  I guessed from the boot
messages that 9LOAD was not starting, and maybe the partition
0 bootloader wasn't starting.  So I booted from the install
cd and took a look at the beginning of the disk with 

cat /dev/sdC0/data | sed 10q 

I was surprised to find the letters "rwm on" right at the 
beginning of the disk.  I saved the output of 

cat /dev/sdC0/data | sed 10q > cat0.out 

at ftp.insolvencyhelp.org/pub/cat0.out if anybody wants to see. 
I decided to reinstall the partition 0 bootloader with 

disk/mbr -m /386/mbr /dev/sdC0/data

after which the machine now seems to boot just fine, and
all the files seem okay too.  For comparison, I saved the
beginning of the disk as it was *subsequent* to reinstalling
the partition 0 bootloader as cat1.out at the previously
mentioned ftp location. 

I mention all this to 9fans because I wonder whether somebody
can tell me, possibly from looking at the other differences
between the two disk images beyond just the "rwm on," what I 
did wrong.  I'm pretty sure that I did *not* type 

echo rwm on > /dev/sdC0/data     /* WRONG */

if that would cause the problem.  I have not tried to 
reproduce the problem, but I could try if people want me 
to do that.  The machine on which this occurred is an x86, 
and the disk is an IDE.  It's still running kfs. 

It certainly is nice to have multiple backups!  :-)
It certainly is nice to have Plan 9.  Thank you to Bell Labs
and 9fans. 

Kindest regards, 

Tom Miller

Re: [9fans] fossil shutdown

[Russ Cox]

> > echo dma on >/dev/sdXX/ctl
> > echo rwm on >/dev/sdXX/ctl

> Inspired, I tried this, and I got an improvement (decrease)
> in time taken to copy files to a new filename of at least
> an order of magnitude.

> I was surprised to find the letters "rwm on" right at the
> beginning of the disk.  I saved the output of

> I'm pretty sure that I did *not* type
>
> echo rwm on > /dev/sdC0/data     /* WRONG */

I'm pretty sure that you did type

    echo dma on >/dev/sdC0/ctl
    echo rwm on >/dev/sdC0/data

explaining both the performance improvement
and the subsequently broken mbr.

The disk fragment you posted on the ftp server
begins with a standard NetBSD mbr except that
the first 7 bytes are "rwm on\n".  This is perfectly
explained by a typo and very hard to explain with
a software or hardware error.

Once I set up a pseudo-worm file server on a few
SCSI disks, spent a few hours populating it, and then
rebooted and the kernel couldn't find the file system.
On inspection, I found postscript code in what should
have been the file server's superblock.  That felt like a
hardware error (shouldn't use discarded machines;
people discard them for a reason!).  This doesn't.

Russ

Re: [9fans] fossil shutdown

[Charles Forsyth]

> Way back on September 22, 2005 Charles Forsyth <forsyth@terzarima.net> 
> wrote:
> [how to set rwm and dma]

i was going to warn at the time against typing the wrong name in sdXX but realised
that might have an effect similar to saying ``don't think of an elephant''.

Re: [9fans] fossil shutdown

[Dave Eckhardt]

> i was going to warn at the time against typing the wrong name in
> sdXX but realised that might have an effect similar to saying
> ``don't think of an elephant'

A couple times I have wondered if it would make sense to
chmod the .../data files once services are running...
or maybe they should start off non-writable and startups
should embody a pattern like this?

 chmod 664 /dev/sdC0/fossil
 fossil -f /dev/sdC0/fossil
 chmod 444 /dev/sdC0/fossil

Dave Eckhardt

Re: [9fans] fossil shutdown

[Russ Cox]

> A couple times I have wondered if it would make sense to
> chmod the .../data files once services are running...
> or maybe they should start off non-writable and startups
> should embody a pattern like this?
>
>  chmod 664 /dev/sdC0/fossil
>  fossil -f /dev/sdC0/fossil
>  chmod 444 /dev/sdC0/fossil

On non-terminals, the problem goes away because only
hostowner has read/write access to them.  Making the disks
read-only by default would just frustrate people who actually
have legitimate use for the disks!  All the programs that
access disks (think dossrv, 9660srv, fdisk, prep, etc.) would
then try to chmod +w, making the permissions somewhat
useless if you're running as hostowner.

Of course, one could put a chmod -w /dev/sd*/data in termrc
if one is worried about making mistakes.

Russ

Re: [9fans] fossil shutdown

[Russ Cox]

> If you've ever tried to venti format a 20GB disk you'd know why it
> sucks to deal with.

If you turn DMA on, formatting the 20GB disk
will be a lot faster.  (All the time is spent zeroing
the disk.)

Russ

Re: [9fans] fossil shutdown

[David Leimbach]

On 9/22/05, Russ Cox <rsc@swtch.com> wrote:
> > If you've ever tried to venti format a 20GB disk you'd know why it
> > sucks to deal with.
>
> If you turn DMA on, formatting the 20GB disk
> will be a lot faster.  (All the time is spent zeroing
> the disk.)
>

If someone adds DMA support for NForce2 based motherboards I'll gladly
do that :).

It's a waste of time though.  Nforce4 is out there now, my stuff is
too old and busted to be worried about.

I'd prefer to work with "the new hotness".

Based on what I've been seeing though [roadmap-wise], my next machine
will likely be Intel and not AMD based.

Dave

> Russ
>

Re: [9fans] fossil shutdown

[David Leimbach]

On 9/22/05, David Leimbach <leimy2k@gmail.com> wrote:
> On 9/22/05, Russ Cox <rsc@swtch.com> wrote:
> > > If you've ever tried to venti format a 20GB disk you'd know why it
> > > sucks to deal with.
> >
> > If you turn DMA on, formatting the 20GB disk
> > will be a lot faster.  (All the time is spent zeroing
> > the disk.)
> >
>
> If someone adds DMA support for NForce2 based motherboards I'll gladly
> do that :).

here's what Plan 9 [or some stage of the bootloader] tells me about my
crappy motherboard.

ELCR: 08A8
apm ax=f000 cx=f000 dx=fdf9 di=0 ebx=7e3c esi=414
dev A0 port 1F0 config 427A capabilities 2F00 mwdma 0007 udma 203F
dev B0 port 1F0 config 427A capabilities 2F00 mwdma 0007 udma 203F
dev A0 port 170 config 427A capabilities 2F00 mwdma 0007 udma 203F
dev B0 port 170 config 85C0 capabilities 0B00 mwdma 0007 udma 0407
pcirouting: South Bridge 10DE, 01E0 not found
ether#0: elnk3: port 0xD000 irq 11: 0026540bd156

Then the plan9.ini file is loaded... so I guess this isn't the kernel
proper but some kind of pre-scan during boot to tell the kernel what
it can figure out about my machine.

Dave

Re: [9fans] fossil shutdown

[Dave Eckhardt]

> If you've ever tried to venti format a 20GB disk you'd know why
> it sucks to deal with.  I don't have 24 hours to wait for it to
> finish as this is also my main linux box for my day job.

If you put your arenas into several smaller partitions instead
of one big one you can fmtarenas each partition independently;
as long as your splits don't loose too much due to fragmentation
your only cost will be that your venti config will be a few lines
longer.

Dave Eckhardt