[9fans] Using cwfs

[9fans] Using cwfs

[Akshat Kumar]

I'm using cwfs(4) for my external harddisks
attached to my CPU server. Is there any
service like /srv/fscons, to which I can
connect with con(1) and get the same
console as with running cwfs normally?
And along the same lines, a way to
"daemonize" cwfs?

Then I wouldn't always have to have a
separate rc window cpu'd into the CPU
server and running cwfs.


Thanks,
ak

Re: [9fans] Using cwfs

[erik quanstrom]

On Sun Aug 23 03:39:38 EDT 2009, akumar@mail.nanosouffle.net wrote:
> I'm using cwfs(4) for my external harddisks
> attached to my CPU server. Is there any
> service like /srv/fscons, to which I can
> connect with con(1) and get the same
> console as with running cwfs normally?
> And along the same lines, a way to
> "daemonize" cwfs?
>
> Then I wouldn't always have to have a
> separate rc window cpu'd into the CPU
> server and running cwfs.

this is a 5-minute hack.  there are probablly
better ways of doing this, but

	srv -e '<cwfs command>' cwfs
	con -C /srv/cwfs

to escape, it's like acme ctl-\ then return.

- erik

Re: [9fans] Using cwfs

[Anthony Sorace]

not directly. on my server running cwfs, i have this in /cfg/<host>/cpustart:
	srv -e 'cwfs -ca tcp!*!54321 -m /sys/lib/arkive/devmap w4' arkivecons
which creates /srv/arkivecons. i can then 'con /srv/arkivecons' to get at the
console in more or less the same way as fscons.

Re: [9fans] Using cwfs

[Akshat Kumar]

Erik wrote:
> this is a 5-minute hack.  there are probablly
> better ways of doing this, but
>
>        srv -e '<cwfs command>' cwfs
>        con -C /srv/cwfs
>
> to escape, it's like acme ctl-\ then return.

Anthony wrote:
> not directly. on my server running cwfs, i have this in /cfg/<host>/cpustart:
>        srv -e 'cwfs -ca tcp!*!54321 -m /sys/lib/arkive/devmap w4' arkivecons
> which creates /srv/arkivecons. i can then 'con /srv/arkivecons' to get at the
> console in more or less the same way as fscons.

Wunderbar! These suggestions works perfectly.


Thank you,
ak

Re: [9fans] Using cwfs

[Akshat Kumar]

I'll use this thread to post further questions about cwfs.

I recently had a problem accessing a directory in a
drive managed by cwfs - whenever I tried to access
the dir, I got the error:
...: phase error -- cannot happen

so I went over to the cwfs console and played around
with `clean':
fs: clean /path/to/trouble
dblock[0] = 286843
dblock[1] = 0
...
iblocks[6] = 0
...
fs: clean /path/to/trouble 286843
... (see above)
fs: clean /path/to/trouble 0
dblock[0] = 286843
dblock[0] modified 0
dblock[1] = 0
...
fs: clean /path/to/trouble
dblock[0] = 0
...

at this point, "uh oh," I thought. I could access
the directory, but of course all files inside were
no longer accessible - just me playing around
a bit. There used to be a 1G file in there; I hope
I can still access it through the worm dump.
I subsequently performed an `rm /path/to/trouble'.
Anyways, a `check rdall' reveals
nmiss = 189296
is this something I should be worried about?
Is the rest of that data inside the directory I
performed a clean 0 on, still dangling somewhere
in the FS, that it should be wiped out? The `check'
shows
nbad = 0
nqbad = 0
but the large number of nmiss still holds my attention.


Best,
ak

Re: [9fans] Using cwfs

[Akshat Kumar]

So, I found the files I lost in an older dump.
Is there any way I can load them from the
dump into the cache without having to copy
them back?

I know bind is an option, but something more
permanent would be better in this case.


ak

Re: [9fans] Using cwfs

[erik quanstrom]

On Sun Aug 23 22:12:54 EDT 2009, akumar@mail.nanosouffle.net wrote:
> ...: phase error -- cannot happen

i haven't ever seen this error.  i would expect
something like this

minooka; lc
ls: .: phase error -- directory entry not allocated

if you are simply left with a directory that's been
deleted.  maybe something else is going on?

> So, I found the files I lost in an older dump.
> Is there any way I can load them from the
> dump into the cache without having to copy
> them back?
>
> I know bind is an option, but something more
> permanent would be better in this case.

i don't know if i can answer your question as
it is without giving an answer that confuses
the issue.

a file can be on the worm, not in the cache
*and* in the active fs.  my version of the fs has the
option to not copy anything to the cache.  this is
generally a good idea as the cache and worm are generally
on similar disks these days.  the active fs is everything
accessable from the main fs without going through
the dump.  of course, if you ever delete or change
something, there are files accessable only through
the dump.

the cache is mostly orthoganal to this.  except
that between dumps, modifications are in the cache,
though they have actually worm addresses.  this is
why some blocks are usually lost on each dump.
since the maximum allocated address on the worm
is never adjusted down to account for deletions.

so the only way to move a file that only exists in
the dump to the active fs is to copy it.

- erik

Re: [9fans] Using cwfs

[Akshat Kumar]

> if you are simply left with a directory that's been
> deleted.  maybe something else is going on?

Perhaps. The harddisk is a FreeAgent Seagate,
connected via USB. It used to go into sleep mode
every 15 minutes and I would often have to restart
cwfs - this is probably cause for a lot of damage.

It's no longer an issue, as I recently got access to
a Windows computer with the proper software to
disable this.

> the cache is mostly orthoganal to this.  except
> that between dumps, modifications are in the cache,
> though they have actually worm addresses.  this is
> why some blocks are usually lost on each dump.
> since the maximum allocated address on the worm
> is never adjusted down to account for deletions.
>
> so the only way to move a file that only exists in
> the dump to the active fs is to copy it.

Makes sense. But does this also mean that when
time comes for a dump, the data will be duplicated
in the WORM? Viz., I'll have two copies of the same
file, in different dumps?


Thanks,
ak

Re: [9fans] Using cwfs

[Mathieu L.]

> > if you are simply left with a directory that's been
> > deleted.  maybe something else is going on?
>
> Perhaps. The harddisk is a FreeAgent Seagate,
> connected via USB. It used to go into sleep mode
> every 15 minutes and I would often have to restart
> cwfs - this is probably cause for a lot of damage.
>
> It's no longer an issue, as I recently got access to
> a Windows computer with the proper software to
> disable this.

I've already told Akumar offlist, just writing it to the list for
documentation:
that auto sleep mode on seagates can be disabled on linux (dunno about
*BSD) as well with sdparm. I don't remember the args for sure, but
probably something like
'sdparm -c STANDBY /dev/sdX#'
then
'sdparm -s /dev/sdX#'
to save.

Mathieu

Re: [9fans] Using cwfs

[erik quanstrom]

> I've already told Akumar offlist, just writing it to the list for
> documentation:
> that auto sleep mode on seagates can be disabled on linux (dunno about
> *BSD) as well with sdparm. I don't remember the args for sure, but
> probably something like
> 'sdparm -c STANDBY /dev/sdX#'
> then
> 'sdparm -s /dev/sdX#'
> to save.

if you have an ata drive and you're using contrib quanstro/sd,
atazz can do the same thing

chula# atazz /dev/sdC0
az> idle sc 0
az> set features disable apm
az>

atazz isn't a magic swiss army knife like (hd|sd)parm.  you can think
of it like a drive console.  imagine you have a glass tty plugged into
your ra05.  except a bazillion times more complicated.

if the drive doesn't support the apm feature set, the second command
will not be supported, but the drive will always be in full-power mode.

the rub is that you must reset these values each time you connect to
an ata device.  the settings can't be saved.  fortunately, the sata drivers
all set the power mode on startup.  you could script atazz to get ide
drivers as well.

if you have a scsi drive, you can do this with scuzz.  you'll need to
cobble together the correct modeselect10 bytes by hand.  i've done
this before, but don't happen to have the correct stuff handy.  sorry.
i should have added the correct incantations when i was working with
it.

- erik

Re: [9fans] Using cwfs

[Akshat Kumar]

I believe there may be an inconsistency somewhere
in the dump records themselves. When I tried to
copy back the file from the dump, into the active
fs, after a while of copying, cwfs panicked with:

main grow ...
    tag = 5/23; expected 757/7 -- not flushed
panic: cwio: checktag c bucket
halted ...

So I ran a `check' after starting up cwfs again, but
nbad = 0
nqbad = 0
although
nmiss = 224455
and still I don't know whether the nmiss is something
that ought to be fixed, or how.
Anyways, the check doesn't seem to reveal any
tag inconsistencies - any suggestions for further tests
in revealing what might be the issue? Or possible
fixes?


Thanks,
ak

Re: [9fans] Using cwfs

[cinap_lenrek]

[-- Attachment #1: Type: text/plain, Size: 362 bytes --]

check if you have the latest version of /sys/src/cmd/cwfs/wren.c
from sources.

the old wrenread()/wrenwrite() used non atomic seek/read/write
sequence that leaves a window for another process moving the file offset
arround under you. this caused wired checktag errors when i tried
to copy my main fileserver to another freshly created cwfs.

--
cinap

[-- Attachment #2: Type: message/rfc822, Size: 3997 bytes --]

From: Akshat Kumar <akumar@mail.nanosouffle.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Using cwfs
Date: Mon, 24 Aug 2009 16:38:51 -0400
Message-ID: <fe41879c0908241338o309657d0t7a9ab0702891055a@mail.gmail.com>

I believe there may be an inconsistency somewhere
in the dump records themselves. When I tried to
copy back the file from the dump, into the active
fs, after a while of copying, cwfs panicked with:

main grow ...
    tag = 5/23; expected 757/7 -- not flushed
panic: cwio: checktag c bucket
halted ...

So I ran a `check' after starting up cwfs again, but
nbad = 0
nqbad = 0
although
nmiss = 224455
and still I don't know whether the nmiss is something
that ought to be fixed, or how.
Anyways, the check doesn't seem to reveal any
tag inconsistencies - any suggestions for further tests
in revealing what might be the issue? Or possible
fixes?


Thanks,
ak

Re: [9fans] Using cwfs

[erik quanstrom]

> Perhaps. The harddisk is a FreeAgent Seagate,
> connected via USB. It used to go into sleep mode
> every 15 minutes and I would often have to restart
> cwfs - this is probably cause for a lot of damage.

this sounds like a bug in usb/disk.  usb/disk should be
able to handle a sleeping drive without passing i/o
errors up.

- erik

Re: [9fans] Using cwfs

[Akshat Kumar]

> this sounds like a bug in usb/disk.  usb/disk should be
> able to handle a sleeping drive without passing i/o
> errors up.

That's probably a USB issue, yes. However, now, I've
setup my drive not to go into sleep mode at all, but
I see the following from earlier today:

...
89806 blocks queued for worm
0 falsehits
next dump at ...
next dump at ...
wrenread: error on w0(1691022): %r
89805 blocks copied to worm

where w0 is the disk itself. Note that the final message
states 89805 blocks were copied, whereas initially
89806 blocks were queued - was the error on just this one
block? If so, what could possibly be the reason? I doubt
my USB drive would be acting up.


Thanks,
ak

Re: [9fans] Using cwfs

[erik quanstrom]

> wrenread: error on w0(1691022): %r

something's wrong here.  %r never prints "%r"
unless errstr is literaly "%r".  does your source
match sources?

> where w0 is the disk itself. Note that the final message
> states 89805 blocks were copied, whereas initially
> 89806 blocks were queued - was the error on just this one
> block? If so, what could possibly be the reason? I doubt
> my USB drive would be acting up.

why couldn't your usb drive have a bad sector or some
other problem?  you could even get less than the requested
number of bytes without an error.  read(2) says that it's
perfectly fine for pread to return less than the requested
number of bytes.  to be really safe, wrenread should use
something like preadn.

i would think that usb would be a bit antisocial if pread
returned less than the requested number of bytes if
RBUFSIZE <= 64k.  but otoh, if it really is a hardware
limit, it would make sense.  we'd just call the hardware
antisocial in that case.  ☺

- erik

Re: [9fans] Using cwfs

[Francisco J Ballesteros]

The disk and controllers are doing almost nothing regarding
suspend. that's a  bug. we'll have to go again over it to add the
bits needed to handle suspend/resume of usb ports and devices
in the right way.

regarding the error I don't know what it could be.
but in any case it shouldn't be %r as Erik said.


On Thu, Aug 27, 2009 at 5:29 AM, erik quanstrom<quanstro@quanstro.net> wrote:
>> wrenread: error on w0(1691022): %r
>
> something's wrong here.  %r never prints "%r"
> unless errstr is literaly "%r".  does your source
> match sources?
>
>> where w0 is the disk itself. Note that the final message
>> states 89805 blocks were copied, whereas initially
>> 89806 blocks were queued - was the error on just this one
>> block? If so, what could possibly be the reason? I doubt
>> my USB drive would be acting up.
>
> why couldn't your usb drive have a bad sector or some
> other problem?  you could even get less than the requested
> number of bytes without an error.  read(2) says that it's
> perfectly fine for pread to return less than the requested
> number of bytes.  to be really safe, wrenread should use
> something like preadn.
>
> i would think that usb would be a bit antisocial if pread
> returned less than the requested number of bytes if
> RBUFSIZE <= 64k.  but otoh, if it really is a hardware
> limit, it would make sense.  we'd just call the hardware
> antisocial in that case.  ☺
>
> - erik
>
>

Re: [9fans] Using cwfs

[erik quanstrom]

On Thu Aug 27 10:11:02 EDT 2009, nemo@lsub.org wrote:
> The disk and controllers are doing almost nothing regarding
> suspend. that's a  bug. we'll have to go again over it to add the
> bits needed to handle suspend/resume of usb ports and devices
> in the right way.

it's probablly going to also be necessary to either
(a) use modeselect (10) to turn off power mgmt (assuming scsi), or
(b) teach usb/disk how to beat its target about the ears
once the usb link has come up until it responds.  kind of
like the online loop for sd devices.

- erik