[9fans] disk/^(mbr format fdisk prep)

[9fans] disk/^(mbr format fdisk prep)

[lucio]

I've been messing around with Flash RAM reading and writing, and I
fell short of being able to produce a disk image indirectly.  To be
more explicit, I tried to create a virtual disk in a conventional file
(/tmp/flash) using the /bin/disk/ utilities, but they seem to fall
short of my objectives, in that they need to write the /dev/sd??/ctl
file which is not available to a virtual disk.  Has anyone considered
writing a fileserver that simulates /dev/sd??  in a file image?  Have
I simply overlooked the obvious?

If it's not been done yet, is it going to be difficult and will anyone
else find it useful?

++L

PS: Is anyone familiar with Flash RAM to the extent that they can
explain why one does not seem to be able to access the entire storage,
for example, using dd?  Or point me to some useful documentation?

Re: [9fans] disk/^(mbr format fdisk prep)

[Charles Forsyth]

>I've been messing around with Flash RAM reading and writing, and I

raw flash is like neither disk nor RAM.  it has many peculiar
properties.  on that you'll need to use something like aux/flashfs on it,
after producing the platform-specific parts for devflash.c.
the format/prep commands don't apply.

possibly you're referring to one of the PC-card or USB flash disks?

Re: [9fans] disk/^(mbr format fdisk prep)

[Kenji Okamoto]

>>I've been messing around with Flash RAM reading and writing, and I

I've gotten to use Flash RAM with IDE interface (IR-ICF01S for example)
as semiconductor disk strage, and now going to use it as our standalone
kfs based AUTH server.   256MB Flash RAM was enough for this purpose.
Thanks Geoff for you suggestion to this.

Kenji

Re: [9fans] disk/^(mbr format fdisk prep)

[Kenji Okamoto]

> Thanks Geoff for you suggestion to this.

A Celeron 366 with 160MB RAM, no floppy, no disks, no CDRPMs etc,
which means no mechanic fans.   No only one fan for power unit.
I got this machine by 24 dollars at Osaka!

This machine may work for Auth server without mechanic trouble.☺

Kenji

Re: [9fans] disk/^(mbr format fdisk prep)

[lucio]

> I've gotten to use Flash RAM with IDE interface (IR-ICF01S for example)
> as semiconductor disk strage, and now going to use it as our standalone
> kfs based AUTH server.   256MB Flash RAM was enough for this purpose.
> Thanks Geoff for you suggestion to this.

The destination equipment seems to get this right (I've not tried so
far), but the intermediate is a Flash RAM writer with a USB interface
- the reason I looked at USB in Plan 9 as some of you may recall;
that's still a pending development, what with OHCI and EHCI needing
implementation from almost scratch.

So at this point I'm at the mercy of a surprisingly helpful NetBSD
environment, but I need Plan 9 to produce the image I eventually write
onto the card.  I could use NetBSD, up to a point, but it's bound to
be a problem once I get to the actual Plan 9 dependent details.  Hence
my interest in a virtual disk simulation file server.

As for Geoff's suggestion, I presume that he and others are aware that
Flash RAM modules are available with the 40-pin IDE connector (male or
female, I believe) built in, try <http://www.simpletech.com>

++L

Re: [9fans] disk/^(mbr format fdisk prep)

[lucio]

> raw flash is like neither disk nor RAM.  it has many peculiar
> properties.  on that you'll need to use something like aux/flashfs on it,
> after producing the platform-specific parts for devflash.c.
> the format/prep commands don't apply.
>
I thought as much.  It was discussed here before, wasn't it.  I had no
reason to pay it attention at the time, but now it rings a bell.
Thank you for the pointer.

> possibly you're referring to one of the PC-card or USB flash disks?

No, I think what I have is raw Flash.  I have a USB reader/writer and
a thin client that treats Flash RAM as IDE (approximately, haven't
quite figured out all the details yet).  The think client is a bit of
a chicken-and-egg situation: it will read/write the Flash but it needs
to boot from it.  Alternatively, it can boot from the IDE drive, but
that seems to hide the Flash away.  I suspect some clever engineering
has gone into making these mutually exclusive.  The documentation is a
bit thin on the ground.

Still, I have it booting 9load from the Flash card, formatted as a DOS disk (disk/format -t hard -d) but I'd like to put a bit more stuff on the flash card and that requires Plan 9 partitioning.

++L

Re: [9fans] disk/^(mbr format fdisk prep)

[Charles Forsyth]

>>No, I think what I have is raw Flash.  I have a USB reader/writer and
>>a thin client that treats Flash RAM as IDE (approximately, haven't
>>quite figured out all the details yet).  The think client is a bit of

it sounds as though you're using Compact Flash, which isn't really
very `raw'.   the Compact Flash cards are commonly accessed
using an ATA (IDE) IO interface, either by initialising in the
same way as PCMCIA (CF and PCMCIA are almost the same
except for form factor and a few other details), or by forcing
it into a default ATA interface directly on power up.
there's a bit more to it than that, but by and large, after setup,
it looks like a disk, and it does all that inside the CF card.
so, unlike raw flash memory, the disk/* commands are indeed
what you'd use, unlike for `raw flash'.

Re: [9fans] disk/^(mbr format fdisk prep)

[Geoff Collyer]

It's not too hard to find PCMCIA adapters for compact flash
cards that make them look like IDE disks, but what I found
(see the archives) was a family of adapters that make a compact
flash card emulate an IDE disk, complete with IDE connector,
or a complete IDE bus with one disk on it, and that plugs straight
into a motherboard IDE connector.  So far they have just worked
for booting my terminal and main cpu server.  We've just moved,
so as I set up machines again, more boot disks will get replaced
by compact flash cards, especially in the file servers.

Re: [9fans] disk/^(mbr format fdisk prep)

[Geoff Collyer]

I've also been thinking of putting /adm/secstore on compact flash.
So far anyway, secstores are pretty small and compact flash cards
aren't subject to head crashes.

Re: [9fans] disk/^(mbr format fdisk prep)

[Kenji Okamoto]

>compact flash cards
> aren't subject to head crashes.

Yeah!, it's the main point I followed your suggestion for our
CF based Auth server.   If we have no mechanical device, it
may not be broken. ☺

Kenji

Re: [9fans] disk/^(mbr format fdisk prep)

[lucio]

> I've also been thinking of putting /adm/secstore on compact flash.
> So far anyway, secstores are pretty small and compact flash cards
> aren't subject to head crashes.

Keep in mind the limited write cycle life, though.  At the very least,
you need to be able to back up the contents before end-of life.  Does
anyone here have specifics?  I presume CF cards just become read-only,
but perhaps they corrupt once their write cycle is exhausted?

++L

Re: [9fans] disk/^(mbr format fdisk prep)

[Kenji Okamoto]

> Keep in mind the limited write cycle life, though.

300,000 cycles per logical sector seems to be long enough
for Auth server, I don't mean CPU server.

Kenji

Re: [9fans] disk/^(mbr format fdisk prep)

[lucio]

>> Keep in mind the limited write cycle life, though.
>
> 300,000 cycles per logical sector seems to be long enough
> for Auth server, I don't mean CPU server.
>
Wow! that seems enough for anything!  Specially Venti :-)

++L

Re: [9fans] disk/^(mbr format fdisk prep)

[Kenji Okamoto]

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

Ok! Now, I started to use Compact Flash as our Auth server's
kfs, which means standalone AUTH server.   We have diskless two
CPU servers and a fileserver in our network.

Let's see what will happen...

The /sys/log directory of the Auth server was imported from that
of a CPU server.

This mail is sent from the new system.

Kenji

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

From: Kenji Okamoto <okamoto@granite.cias.osakafu-u.ac.jp>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] disk/^(mbr format fdisk prep)
Date: Mon, 10 May 2004 14:25:34 +0900
Message-ID: <e81d56074d786b757046e31a190d1aea@granite.cias.osakafu-u.ac.jp>

> Keep in mind the limited write cycle life, though.

300,000 cycles per logical sector seems to be long enough
for Auth server, I don't mean CPU server.

Kenji

Re: [9fans] disk/^(mbr format fdisk prep)

[boyd, rounin]

from a reliable source, i heard that flash mem cards are good good for 1M
write ops.

choose your use of this thing carefully.   iirc kfs 'syncs' dirty blocks
every 15 secs.

300K or 1M are not large numbers.

Re: [9fans] disk/^(mbr format fdisk prep)

[Kenji Okamoto]

> choose your use of this thing carefully.   iirc kfs 'syncs' dirty blocks
> every 15 secs.

All the 'dirty' blocks of this AUTH server should be in /sys/log, I guess.
Please let me know if I'm wrong.

Kenji

[9fans] Compact Flash standalone AUTH server

[Kenji Okamoto]

> Ok! Now, I started to use Compact Flash as our Auth server's
> kfs, which means standalone AUTH server.

The machine is floppy- disk-less Celeron 366MHz Mitsubishi
Aprocot CX-200 (very old machine!) with 160MB SDRAM.
This machine has LAN card on its board (i82557).

The Compact Flash is Toshiba THNCF256MMA (256MB), and
an IDE interface card of "IR-ICF01S".   This machine does only
/bin/service.auth.

Kenji

Re: [9fans] Compact Flash standalone AUTH server

[Kenji Okamoto]

>> Ok! Now, I started to use Compact Flash as our Auth server's
>> kfs, which means standalone AUTH server.

Today, I started to have double file servers, Ken's file server and
Fossil+Venti file server here.   Some terminals and a CPU server use Ken's,
and other terminal and a CPU server use Fossil+Venti.
Let's see how this Plan 9 network works from now.

Kenji

Re: [9fans] Compact Flash standalone AUTH server

[Kenji Okamoto]

> and other terminal and a CPU server use Fossil+Venti.

s/other terminal/other terminals/ ☺

Kenji

Re: [9fans] Compact Flash standalone AUTH server

[Kenji Okamoto]

> Today, I started to have double file servers, Ken's file server and
> Fossil+Venti file server here.   Some terminals and a CPU server use Ken's,
> and other terminal and a CPU server use Fossil+Venti.
> Let's see how this Plan 9 network works from now.

It's interesting to have two file servers and two CPU servers.
I can see what the real action on Plan 9 system is happening.
I couldn't stop to shutup my mouth, sorry.

Kenji

Re: [9fans] Compact Flash standalone AUTH server

[Kenji Okamoto]

> I couldn't stop to shutup my mouth, sorry.

s/sutup/open/  ☺

Anyway, I'm trying to switch the file server from plan9.ini
file of a terminal.

When I change ip/ipconfig line by adding bootargs like
bootargs=tcp -g <ip address of the gateway> ether /net/ether0 <ip address of the terminal> 255.255.255.0 0 <ip address of the file server> <ip address of the auth server> ,
I can switch the file server successfully.

However, I want to do it just adding a line of
fs=<file server>.

I'm using DHCP, and have a line of ip/ipconfig as
if(! test -e /net/ipifc/0/ctl)
	ip/ipconfig >/dev/null >[2=1].

I don't want to have if(~ $sysname 'abcdefg') in termrc
file...

Why ading the
fs=<file server>
line doesn't work?

Kenji

Re: [9fans] Compact Flash standalone AUTH server

[Kenji Okamoto]

> Why ading the
> fs=<file server>
> line doesn't work?

I meant isn't it better to overwrite the fs or auth value
by plan9.ini file.

Kenji

Re: [9fans] Compact Flash standalone AUTH server

[Kenji Okamoto]

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

It has passed about a month from we started to use CompactFlash
based kfs standalone AUTH server here.

The AUTH server is now counted 13650 process number, and has
not have no problem so far.   I'm now leaning to have convice it
is useful for this purpose.

If someone wants to make this kind of stanalone AUTH server,
I reccommend you to go.   To have standalone AUTH server is
good for anyone who wants to have multiple file servers, such
as Fossil+Venti and Ken's file server.   Furthermore, it has no
mechanical disks, no floppy, no CDROM, no disk, we have no
element to be broken accidentally.☺

Kenji

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

From: Kenji Okamoto <okamoto@granite.cias.osakafu-u.ac.jp>
To: 9fans@cse.psu.edu
Subject: [9fans] Compact Flash standalone AUTH server
Date: Thu, 13 May 2004 11:43:22 +0900
Message-ID: <da9c1c20ee3d9a4068786df15caace9c@granite.cias.osakafu-u.ac.jp>

> Ok! Now, I started to use Compact Flash as our Auth server's
> kfs, which means standalone AUTH server.   

The machine is floppy- disk-less Celeron 366MHz Mitsubishi
Aprocot CX-200 (very old machine!) with 160MB SDRAM.
This machine has LAN card on its board (i82557).

The Compact Flash is Toshiba THNCF256MMA (256MB), and
an IDE interface card of "IR-ICF01S".   This machine does only
/bin/service.auth.

Kenji

Re: [9fans] Compact Flash standalone AUTH server

[Kenji Okamoto]

> The AUTH server is now counted 13650 process number, 

This is of course for AUTH server, not CPU server.

Kenji

Re: [9fans] disk/^(mbr format fdisk prep)

[lucio]

> It's not too hard to find PCMCIA adapters for compact flash
> cards that make them look like IDE disks, but what I found
> (see the archives) was a family of adapters that make a compact
> flash card emulate an IDE disk, complete with IDE connector,
> or a complete IDE bus with one disk on it, and that plugs straight
> into a motherboard IDE connector.  So far they have just worked
> for booting my terminal and main cpu server.  We've just moved,
> so as I set up machines again, more boot disks will get replaced
> by compact flash cards, especially in the file servers.

That's on my list of things to source.  The other, which I mentioned,
is an IDE connector attached to a printed circuit board with two chips
on it, I presume one is Flash RAM, the other ATA interfacing.  But
right now I need to use what I already have, which I mentioned in a
previous message.

But I am grateful for all suggestions, I may just not be able to
pursue each and every one of them :-)

++L

Re: [9fans] disk/^(mbr format fdisk prep)

[lucio]

> If it's not been done yet, is it going to be difficult and will anyone
> else find it useful?

Well, call me stupid!  mksacfs(8) and sacfs(4).  I'm going to try it.

++L

Re: [9fans] disk/^(mbr format fdisk prep)

[Fco.J.Ballesteros]

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

The bitsy is using paqfs instead of sacfs. Perhaps you'd want
to look at them too.

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

From: lucio@proxima.alt.za
To: 9fans@cse.psu.edu
Subject: Re: [9fans] disk/^(mbr format fdisk prep)
Date: Sat, 8 May 2004 11:56:14 +0200
Message-ID: <51bdf33d3f21cd9477dcf67a9a90938e@proxima.alt.za>

> If it's not been done yet, is it going to be difficult and will anyone
> else find it useful?

Well, call me stupid!  mksacfs(8) and sacfs(4).  I'm going to try it.

++L

Re: [9fans] disk/^(mbr format fdisk prep)

[lucio]

> The bitsy is using paqfs instead of sacfs. Perhaps you'd want
> to look at them too.

It seems to me that some rationalisation of all these little tools
would not go amiss.  But maybe all that is needed is a little more
documentation.  Aux/disksim would be my first choice, I'm not sure if
I can muster enough enthusiasm to do it or will just resign myself to
a permanent feeling of guilt :-(

++L

Re: [9fans] disk/^(mbr format fdisk prep)

[Richard Miller]

The disk utilities do work with regular files (see the last few lines of
/sys/src/libdisk/disk.c), but you probably need to preallocate one of
the required size.  Try dd -if /dev/zero ...

-- Richard

Re: [9fans] disk/^(mbr format fdisk prep)

[lucio]

> The disk utilities do work with regular files (see the last few lines of
> /sys/src/libdisk/disk.c), but you probably need to preallocate one of
> the required size.  Try dd -if /dev/zero ...

I did, that was the bit about less storage than the stated capacity.
Perhaps you can clarify how partitioning would work?  I hope I'm not
the only one that would need to consult the sources to understand the
finer details.

++L

Re: [9fans] disk/^(mbr format fdisk prep)

[Richard Miller]

> Perhaps you can clarify how partitioning would work?

You can use the fs(3) device for partitioning - you have to do a bit
of arithmetic because the 'part' commands in fs(3) and sd(3) have
different semantics (and syntax).

-- Richard

Re: [9fans] disk/^(mbr format fdisk prep)

[lucio]

> You can use the fs(3) device for partitioning - you have to do a bit
> of arithmetic because the 'part' commands in fs(3) and sd(3) have
> different semantics (and syntax).

That's an idea.  Nearly ten years of exposure to Plan 9 and still
plenty to learn...

++L