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

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

[YAMANASHI Takeshi]

On Thu May 13 11:49:50 JST 2004, Kenji Okamoto wrote:
> All the 'dirty' blocks of this AUTH server should be in /sys/log, I guess.

Everytime /bin/service.auth/tcp567 is started,
the last access time is updated.  Then there are
other binaris to be executed on AS and so on...

Correct me if I'm wrong, too.
--

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

[Kenji Okamoto]

> Everytime /bin/service.auth/tcp567 is started,
> the last access time is updated.  Then there are
> other binaris to be executed on AS and so on...

Then, this AUTH server may die within several to ten's
of several days.   Let's see it...

Kenji

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

[Kenji Okamoto]

> Then, this AUTH server may die within several to ten's
> of several days.   Let's see it...

Shuld be multiplied 100. ☺

Kenji

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

[Richard Miller]

Many (most?) flash devices do "wear-levelling": blocks which are being
frequently rewritten will be periodically remapped by the firmware or
driver so that erase activity is spread evenly across all blocks.  So
it is the average number of writes per block which determines the
device life expectancy, not the peak number.

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

[lucio]

> Many (most?) flash devices do "wear-levelling": blocks which are being
> frequently rewritten will be periodically remapped by the firmware or
> driver so that erase activity is spread evenly across all blocks.  So
> it is the average number of writes per block which determines the
> device life expectancy, not the peak number.

Well, now that's clever.  Of course, it is obvious, too.  But can one
rely on this?  Is there some way of detecting when things start going
wrong?  What would the symptoms be?

++L

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

[Richard Miller]

>> Many (most?) flash devices do "wear-levelling"...

> But can one
> rely on this?

The documentation for the device ought to say something about it.

> ...  Is there some way of detecting when things start going
> wrong?  What would the symptoms be?

My understanding is that failure is progressive: as a flash block
"wears out', write / erase operations take longer and longer to
complete, until eventually they take forever.

-- Richard

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

[Charles Forsyth]

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

see the `atime' console command in kfscmd(8).  you could add it as an option to
kfs itself.

if you aren't terribly worried about logging everything, you could
run aux/listen with -q to reduce logging chatter.

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

From: YAMANASHI Takeshi <uncover@beat.cc.titech.ac.jp>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] disk/^(mbr format fdisk prep)
Date: Thu, 13 May 2004 11:57:37 +0900
Message-ID: <2a2f13faee87856b7686b122a9cb1830@orthanc.cc.titech.ac.jp>

On Thu May 13 11:49:50 JST 2004, Kenji Okamoto wrote:
> All the 'dirty' blocks of this AUTH server should be in /sys/log, I guess.

Everytime /bin/service.auth/tcp567 is started,
the last access time is updated.  Then there are
other binaris to be executed on AS and so on...

Correct me if I'm wrong, too.
--

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

[Kenji Okamoto]

> see the `atime' console command in kfscmd(8).  you could add it as an option to
> kfs itself.

done, today.

Kenji

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

[dvd]

> see the `atime' console command in kfscmd(8).  you could add it as an option to
> kfs itself.

the only problem is that I could not install kfs on a compactflash -- it is terribly
slow. Fossil has been fine.

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

[ron minnich]

On Thu, 13 May 2004 lucio@proxima.alt.za wrote:

> Well, now that's clever.  Of course, it is obvious, too.  But can one
> rely on this?  Is there some way of detecting when things start going
> wrong?  What would the symptoms be?

you'll know. You'll get data corruption as writes fail to occur.

ron

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

[Charles Forsyth]

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

i have used kfs happily on a compact flash (some time ago admittedly),
and i couldn't work out why i fared better.

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

From: dvd@davidashen.net
To: 9fans@cse.psu.edu
Subject: Re: [9fans] disk/^(mbr format fdisk prep)
Date: Thu, 13 May 2004 17:45:54 +0500
Message-ID: <fd789d903b2908907314bafb58ba8f1a@davidashen.net>

> see the `atime' console command in kfscmd(8).  you could add it as an option to
> kfs itself.

the only problem is that I could not install kfs on a compactflash -- it is terribly
slow. Fossil has been fine.

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

[dvd]

> i have used kfs happily on a compact flash (some time ago admittedly),
> and i couldn't work out why i fared better.


I used cf->Ide adapter from the ituner store.  It was a recent plan9 cd image;
the installer was copying files to the CF at  about  64Kb/s. The CF is Toshiba MMA
512Mb.

With fossil, it has been much faster.

David

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

[Charles Forsyth]

>>With fossil, it has been much faster.

i would expect fossil to be faster; i was just surprised that
kfs was unusably slow.   kfs does write all metadata through to disk when
running as  a localfs (that can be switched off in the code), although it does
buffer data writes.  fossil doesn't, as you observed much earlier.
clearly that makes an enormous difference on CF (now at least).
it could be too that i wasn't expecting much speed from it at the time i did it.

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

[Joel Salomon]

Richard Miller said:
> Many (most?) flash devices do "wear-levelling": blocks which are being
> frequently rewritten will be periodically remapped by the firmware or
> driver so that erase activity is spread evenly across all blocks.  So
> it is the average number of writes per block which determines the
> device life expectancy, not the peak number.
>
Reading some linux docs (jffs,jffs2,yaffs), it seems the load leveling is
a function of the file system/driver, not firmware.


--Joel

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

[boyd, rounin]

> Reading some linux docs (jffs,jffs2,yaffs), it seems the load leveling is
> a function of the file system/driver, not firmware.

that would make more sense.  adding more h/w to avoid flakey h/w
just doesn't make sense.   and, as ron said, you'll know when the
media flakes -- reads that fail or return trash and writes that fail.

i have noticed that memory stick acccesses are not exactly quick.
so much to read, so little time.

i see my USB flash ram says:

    data retention: > 10 years
    reads: 1Mb/s
    writes: 750Kb/s

just a bit slower than a MASSBUS disk.

nice to be able to carry the whole dist on my 256Mb version (they go up to
2Gb), which has been 'round the world once :)

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

[Nigel Roles]

> Reading some linux docs (jffs,jffs2,yaffs), it seems the load
> leveling is a function of the file system/driver, not firmware.
>
>

This depends entirely on the technology involved. There are
intelligent flash systems (CF, SD, MM) which emulate disk
drives (e.g. CF can be connected directly to an IDE controller);
these do the wear levelling themselves.

Then there are the unintelligent technologies (NOR flash,
NAND flash, SmartMedia, SSFD) which don't.

Of course, the intelligent ones are built out of the
unintelligent ones with a controller in the way.

There are really only two kinds of flash; NOR and NAND.
The latter does it on 2 transistors per cell; the former
4. The latter is faster to program and erase, but loses
storage faster with age.

SmartMedia/SSFD is just a fancy name and packaging
for NAND flash.

So, jffs/jffs2/yaffs are designed to work direct onto
NOR/NAND flash, hence they have wear-levelling. It is
particularly important to do this for NAND flash for
a variety of reasons I shan't bore with.

Nigel

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

[matt]

from what I have read the silicon marks the cells as bad and skips them such that the overall capacity is reduced as the cells wear out

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

[boyd, rounin]

> So, jffs/jffs2/yaffs are designed to work direct onto
> NOR/NAND flash, hence they have wear-levelling.

i think this is a complete waste of time.  it adds complexity
and the YAFS [Yet Another File System] syndrome.

such things should just appear as raw disks and you
stick whatever f/s you like on 'em.

if you want to wear-level it stick a user mode wear-leveller on top of it.
isn't that what plan 9 does really well?

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

[ron minnich]

On Thu, 13 May 2004, Joel Salomon wrote:

> Reading some linux docs (jffs,jffs2,yaffs), it seems the load leveling is
> a function of the file system/driver, not firmware.

M-systems used to advertise that they did load leveling in their parts (I
think ...)

ron

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

[Joel Salomon]

boyd, rounin said:
>> So, jffs/jffs2/yaffs are designed to work direct onto
>> NOR/NAND flash, hence they have wear-levelling.
>
> i think this is a complete waste of time.  it adds complexity
> and the YAFS [Yet Another File System] syndrome.
>
> such things should just appear as raw disks and you
> stick whatever f/s you like on 'em.
>
> if you want to wear-level it stick a user mode wear-leveller on top of it.
> isn't that what plan 9 does really well?
>

How would one go about adding a "user mode wear-leveller" atop kfs, for
example? general outline is okay.

--Joel

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

[boyd, rounin]

> How would one go about adding a "user mode wear-leveller" atop kfs, for
> example? general outline is okay.

kfs was a hack to get it onto the x86.  said hack has proven
to be very stable, unlike fossil.  even the worm ran a f/s kernel
that had nothing to do with plan 9, except it talked 9p and
could return Erob.

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

[Charles Forsyth]

>>How would one go about adding a "user mode wear-leveller" atop kfs, for
>>example? general outline is okay.

i'm not sure it is.  it needs to take account of physical not logical
location, because it's the wear on the physical location that matters,
and perhaps the topology-- for instance, depending on the flash and
algorithm it might be necessary to move the same block content from
one physical block to another without changing the logical address--or
on some flash move every block within a flash segment at least once
every 10,000 writes-- and if `such things should just appear as raw
disks' the physical location won't be visible to the higher level file
system without an interface peculiar to flash.

that's why the usual approach to providing a `raw disk' on top of flash
sits below the file system, not above it.  it's still not as efficient as a storage system
designed for flash.

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

[boyd, rounin]

> it's still not as efficient as a storage system designed for flash.

tin gods.  i'd like it to be fast, but i'd go for reliability first.

obviously, you choose your storage media based on
its properties and what your use of it will be.

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

[Charles Forsyth]

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

by efficient, i meant not wearing it out too fast,
not speed.  the reliability of flash can depend critically
on the update strategy and tactics.

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

From: "boyd, rounin" <boyd@insultant.net>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] disk/^(mbr format fdisk prep)
Date: Fri, 14 May 2004 00:31:11 +0200
Message-ID: <024f01c43939$ffb35b40$127e7d50@SOMA>

> it's still not as efficient as a storage system designed for flash.

tin gods.  i'd like it to be fast, but i'd go for reliability first.

obviously, you choose your storage media based on
its properties and what your use of it will be.

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

[Charles Forsyth]

>>M-systems used to advertise that they did load leveling in their parts (I
>>think ...)

yes, and CF cards do something similar.

even so, one also needs to take account of `wear reducing', and that can
require knowledge of topology and application, and control
of strategy, all of which are conveniently located in a file
server that knows about the peculiar properties of the medium.
even the design of the storage structure for a file system
can depend on the flash characteristics.

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

[boyd, rounin]

> by efficient, i meant not wearing it out too fast, not speed

right, but it still smacks of shitty h/w.

heavy as it was, the RM03 was a decent piece of media [80Mb].

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

[Joel Salomon]

Charles Forsyth said:
>>>How would one go about adding a "user mode wear-leveller" atop kfs, for
>>>example? general outline is okay.
>
> i'm not sure it is.  it needs to take account of physical not logical
> location, because it's the wear on the physical location that matters,
> and perhaps the topology--
<snip>
> that's why the usual approach to providing a `raw disk' on top of flash
> sits below the file system, not above it.  it's still not as efficient as
> a storage system
> designed for flash.
>

got it -  i understood
> if you want to wear-level it stick a user mode wear-leveller on top of it.
> isn't that what plan 9 does really well?
to mean a wear leveler on top of the file system & was at loss to see how
that might be done (probably because it can't)

Then what would the leveler look like, boyd? I'm guessing some file whose
offsets point to different parts of the flash, depending on use, which
can't easily be done under anything but p9. is that it?

--Joel

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

[Charles Forsyth]

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

not necessarily shitty h/w: it depends whether its properties suit your app.
(even with discs you could end up with an RL02, which had no idea where its head was.)
if you want to rewrite blocks indefinitely, don't use WORM or FLASH.
WORMS are good for archival storage but you can't write even twice to a WORM block.
in fact, that's a reasonably good analogy: because worms
are `different' somewhat different strategies are used by a file system to
allocate blocks for instance.  (eg, the `next' pointer
in the current super block might point to an allocated
but blank one, and so on.)

it's certainly true that people often assume they can exchange
magnetic devices and flash in a casual way.
is 100,000 a big number?  it might be.
is 1,000,000 a big number?  it might not be.
i carry a USB flash device to hold information that's updated at most twice a day.
even 10,000 is a big number then.

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

From: "boyd, rounin" <boyd@insultant.net>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] disk/^(mbr format fdisk prep)
Date: Fri, 14 May 2004 00:41:49 +0200
Message-ID: <026a01c4393b$7a9f2400$127e7d50@SOMA>

> by efficient, i meant not wearing it out too fast, not speed

right, but it still smacks of shitty h/w.

heavy as it was, the RM03 was a decent piece of media [80Mb].

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

[boyd, rounin]

> (even with discs you could end up with an RL02, which had no idea where
its head was.)

nasty thing the RL02.  had some on an 11/23 once which i hacked 2BSD (?)
'segment swapping' (for want of a better word) so the lusers could run
vi(1).

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

[boyd, rounin]

> Then what would the leveler look like, boyd? I'm guessing some file whose
> offsets point to different parts of the flash, depending on use, which
> can't easily be done under anything but p9. is that it?

it's late etc, but fossil it an example of an interface between 9p
and something [venti] that only knows about blobs.

it depends on the media, but it should look like a raw disk.
if you want to tweak its lifetime or performance then you have
a meta-data chunk [partition] to explain its layout -- whatever.

a user mode f/s can do what it likes, but the underlying media
should look like a raw disk.

all this is well understood.  even the MD is a f/s.

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

[Russ Cox]

> > How would one go about adding a "user mode wear-leveller" atop kfs, for
> > example? general outline is okay.
>
> kfs was a hack to get it onto the x86.  said hack has proven
> to be very stable, unlike fossil.  even the worm ran a f/s kernel
> that had nothing to do with plan 9, except it talked 9p and
> could return Erob.

mark?  mark v. shaney?  is that you?

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

[boyd, rounin]

> mark?  mark v. shaney?  is that you?

yeah, it is.  my idea.  brucee's & rob's implementation using don mitchell's
code.

    http://en.wikipedia.org/wiki/Mark_V_Shaney

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

[boyd, rounin]

> mark?  mark v. shaney?  is that you?

brahma% pwd
/n/sources/plan9/sys/src/fs
brahma% grep -i 'rob made' */*.[ch]
port/data.c: [0x70] "rob made me do it",

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

[Kenji Okamoto]

> With fossil, it has been much faster.

Why I didn't employ fossil this time, because I needed fully robust file
system for this AUTH server.   I needed this standalone AUTH server,
because I don't want to depend its function to any one of file servers
themselves.   I'm going to live with double file server, Ken's and Fossil
+Venti soon, where we have to keep all our system non-stop.   So the
robust and standalone AUTH server was necessary.

For the speed of kfs on CF, I agree with thatit's terriblly slow to write
to kfs on CF, which made me much surprise.   I had to play with web
browser wen I was installing things to that CF kfs.   However, we need
mainly just reading from this CF kfs for AUTH server, then, speed issue
is not serious to me.

Kenji

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

[dvd]

>> With fossil, it has been much faster.
>
> Why I didn't employ fossil this time, because I needed fully robust file
> system for this AUTH server.   I needed this standalone AUTH server,

I don't fully understand the concern. Right now, mini-box with CF and fossil
(without venti) on it is my only Plan 9 machine, standalone cpu+file server+auth.
What's wrong with fossil for that?

David

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

[Kenji Okamoto]

> I don't fully understand the concern. Right now, mini-box with CF and fossil
> (without venti) on it is my only Plan 9 machine, standalone cpu+file server+auth.
> What's wrong with fossil for that?

Because none sayes about unstability of Ken's fs or kfs, but some do for
fossil things.   Of course some of them should be from wrong usage of it.
However, I can't have confidnce that it's stable enough for our site.

I'm using fossil+venti+cpu+auth server at home fully safely.   However,
its system is not loaded so high where only one user of myself all the time,
and which is also said many times here.

Kenji

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

[ron minnich]

On Fri, 14 May 2004, boyd, rounin wrote:

> right, but it still smacks of shitty h/w.

the wearing out thing is really weird. My (4 year old) reading about flash
led me to believe the process was close to electrochemical and the cells
gradually wear out with repeated transitions.

So it's great for ROM, ok for PROM (how we use it here), lousy for normal
disk usage.

ron

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

[boyd, rounin]

> So it's great for ROM, ok for PROM (how we use it here), lousy for normal
> disk usage.

i'm with you, captain.

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

[David Tolpin]

Kenji Okamoto:
> > I don't fully understand the concern. Right now, mini-box with CF and fossil
> > (without venti) on it is my only Plan 9 machine, standalone cpu+file server+auth.
> > What's wrong with fossil for that?
>
> Because none sayes about unstability of Ken's fs or kfs, but some do for
> fossil things.   Of course some of them should be from wrong usage of it.
> However, I can't have confidnce that it's stable enough for our site.

I am saying about instability of kfs.
I am getting the same bug on several different computers,
unless a fix is applied. When kfs is rebooted after power failure,
it reports wrenwrite errors in endless loop.

The fix is to flush dirty blocks to disk after checking and reparing
and before kfs is launched. The fix is simple, but the problem
is that I can't understand  why it matters. It is a race, if enough
debuggin output is added, the bug disappears due to accidental slowdown.

Everyone has UPSes these days, so people just don't notice.

Not everyone lives in a region when blackouts last for hours
occasionally.

David

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

[Kenji Okamoto]

> Not everyone lives in a region when blackouts last for hours
> occasionally.

The last time when we experienced blackout without pre-announcement, 
I don't remember it.   Probably it may before 30 years ago. ☺

Kenji

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

[a]

// [kfs] has proven to be very stable, unlike fossil.

i've never found kfs to be particularly reliable when compared
to other file systems. quite the opposite, actualy. my first
hand experience with fossil is more limited (i've not converted
my file server from ken's to fossil 
away), but so far i'm much more pleased with it than kfs.

// ...a f/s kernel that had nothing to do with plan 9...

my understanding was that it was based on an early fork of the
kernel with the user-mode stuff removed. is that incorrect?
ア

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

[a]

// Because none sayes about unstability of Ken's fs or kfs,
// but some do for fossil things.

based on my own readings here, i think people say plenty of
bad things about kfs. we just hear them less because kfs was
never billed as something suitable for a file server. it
also seems to me that most of the complaints about fossil
not all) were early on, and that it's stabalized much since.

i wish abbreviating "Ken's FS" didn't yeild "kfs".
ア

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

[Joel Salomon]

> Not everyone lives in a region when blackouts last for hours
> occasionally.
>
I'm in new york - blackout lasted nearly a full day, some neighborhoods...

--Joel

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

[a]

// I'm in new york - blackout lasted nearly a full day, some neighborhoods...

well over, in some.

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

[Sape Mullender]

> // I'm in new york - blackout lasted nearly a full day, some neighborhoods...
>
> well over, in some.

Great.  The my-blackout's-bigger-than-yours discussion!

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

[dvd]

> // I'm in new york - blackout lasted nearly a full day, some neighborhoods...
>
> well over, in some.

Then you should have noticed that kfs does not come up nicely after
power failure.  In Yerevan, where I live, blackouts these days are not
due to lack of power production, but to frequent failures of warn out
equipment; approximately two powerless half-hours per week and one
serious failuer (several hours) per month.

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

[andrey mirtchovski]

On Fri, 14 May 2004, Sape Mullender wrote:

> Great.  The my-blackout's-bigger-than-yours discussion!
>

true story:

when i was a kid growing up in a well known eastern bloc country we had
electricity shortages in the winter. our government had made contracts for
exporting electricity from the nuclear power plant to turkey and greece, and
during the winter months, when power consumption peaked, there simply wasn't
enough to go around locally.

we had electricity for 3 hours, then 3 hours blackout, repeat. they
'd turn it on in one part of the city and turn it off somewhere else.
that was all government mandated!

next winter it was 1:3 -- 1 hour blackout, three hours with electricity.

this continued for three-four years -- every  winter the country looked
like a diskotheque.

andrey

ps: relevance? what relevance?

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

[a]

// Great.  The my-blackout's-bigger-than-yours discussion!

not my intent; wasn't my blackout, i was just far enough south
that i never lost power. just correcting some facts.
ア

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

[a]

// Then you should have noticed that kfs does not come up nicely
// after power failure.

um, yeah, i have noticed that. and had said earlier that i didn't find
kfs to be particularly reliable.
ア

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

[ron minnich]

On Fri, 14 May 2004, andrey mirtchovski wrote:

> this continued for three-four years -- every  winter the country looked
> like a diskotheque.

that's why you couldn't get your MSCA.

ron

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

[andrey mirtchovski]

> that's why you couldn't get your MSCA.
>
> ron

no microsoft back then.  we had our own reverse-engineered PC-DOS
operating systems running on the reverse engineered PC's we (not me,
of course) were making.

the apple II clones:

	http://bulgariancomputers.freeservers.com/pravetz-82/index_eng.html
	http://www.mess.org/sysinfo/prav8d.htm

there's a links there to a txt file detailing some more about the 8086 clones.

no MCSA, but they started an official cisco academy in my home town a
few years ago.  you can cue in jokes about the physical training
required to run quickly to the server room whenever the power goes out
any time now.

andrey

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

[Geoff Collyer]

When I asked 1127 folks what the "k" in "kfs"
stood for (and suggested "kludge"), they said
it stood for "Ken".  The on-disk formats of kfs
and /sys/src/fs are clearly related, with kfs's
intended to permit easily parameterising the
block size.  I have used a modified kfs to
recover data from a damaged Ken fs.  kfs is
roughly a subset of Ken fs; perhaps distinguishing
user vs. kernel or standalone vs. non-standalone
would clarify which "kfs" or "ken fs" we mean.

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

[Adrian Tritschler]

On Fri, 14 May 2004 19:17, Kenji Okamoto wrote:
> > Not everyone lives in a region when blackouts last for hours
> > occasionally.
>
> The last time when we experienced blackout without pre-announcement,
> I don't remember it.   Probably it may before 30 years ago. ☺

Wow.  No big blackouts here, just lots 'n lots of little ones.

Here in the third world...Ok, Melbourne, Australia, I'm lucky if the PC at 
home runs for four weeks without a power outage that forces a reboot.  They 
might only be momentary, maybe upto few seconds, but resetting every clock in 
the phone, the microwave, the alarms, etc, around the place is getting to be 
a major pain.

The wonder that is our privatised electricity network, maximum profit, minimum 
maintenance...

     1   123 days, 06:17:47 | Linux 2.4.20            Mon Jun  2 18:19:15 2003
     2   110 days, 19:51:16 | Linux 2.4.20            Wed Dec  4 20:53:55 2002
     3    52 days, 00:01:53 | Linux 2.4.18            Tue Sep  3 17:53:52 2002
     4    34 days, 21:38:02 | Linux 2.4.24            Tue Feb 24 18:38:53 2004
     5    32 days, 03:53:20 | Linux 2.4.20            Fri Apr  4 18:47:57 2003
     6    23 days, 14:42:10 | Linux 2.4.20            Sun Oct  5 19:46:50 2003
     7    22 days, 23:30:03 | Linux 2.4.18            Thu Oct 31 16:53:11 2002
->   8    21 days, 22:18:38 | Linux 2.4.25            Fri Apr 23 19:34:18 2004
     9    15 days, 10:36:07 | Linux 2.4.24            Tue Mar 30 16:55:21 2004
    10    14 days, 00:01:04 | Linux 2.4.20            Sat May 17 16:19:53 2003
    11    12 days, 20:01:49 | Linux 2.4.22            Thu Nov  6 21:46:13 2003
    12    11 days, 03:27:08 | Linux 2.4.18            Sat Nov 23 16:24:55 2002
    13    10 days, 05:12:44 | Linux 2.4.20            Tue May  6 22:45:37 2003

No comments on the OS, please!  And don't tell me I should buy a UPS, I think 
I already know that.

	Adrian

> Kenji

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

[boyd, rounin]

> Here in the third world...Ok, Melbourne, Australia, ...

yeah, interesting how the banks have shut up shop in the smaller towns.
even citibank in sydney have only 1 branch and that's for business customers
only.

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

[Kenji Okamoto]

By the way, I got rid of /sys/log/auth and /sys/log/ipboot
from kfs of the AUTH server, and toggled off the atime.
Now, I don't see cyclic 'disk' access LED on the machine,
and see the messages to the cosole.   I think the machine
tuned for CF memory now...

Kenji

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

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]

[-- 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)

[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)

[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]

>> 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]

> 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]

> 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)

[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]

> that's my guess and i've got a USB one.  on windows it looks like
> a disk, but i'm damn sure there's a lot of guff in there to make it
> look like a disk.  i can't imagine it to be pretty.

I ought to wait until I've had a chance to get my wits about me, but
what needs to be mentioned is that I have two distinct issues here: a
"compact flash" card (thanks, forsyth) and a USB-based reader-writer
(with four slots, by the way, I have no idea what to do with three of
them).

I can't use the CF card under Plan 9 just yet, nor the USB
reader-writer, but I want the CF to have a bootable Plan 9 image on
it.  Ideally, I'd like to choose between Plan 9 and NetBSD, as the
Plan 9 features I want are still being developed (USB, graphics etc.)
whereas NetBSD already supports them.

I haven't yet exhausted all the possibility, nor really identified and
studied them.  But I have been given plenty of information from
contributors on the list and I'm glad that the information is being
archived as I'm sure other will also benefit from the advice.

++L

PS: In fact, I _can_ now write the CF card on the thin client, where
it is presently seen as a somewhat weird IDE disk (I'll post the
details elsewhere just for curiosity, I think something needs fixing
in disk/fdisk), but I'm reluctant to do so as it's the only device and
if I overwrite its current configuration booting Plan 9 the thin
clients may become an impossibility.  Once I'm more confident, I'll
try that path.  For the time being, I want a somewhat less risky
approach.

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

[lucio]

> Although it doesn't sound like it's what you want anymore,
> you could use aux/disksim to get an sd(3)-like interface
> to an arbitrary file.

I think I actually still need this, thanks for pointing me in that
direction.  I'm a bit swamped with options that I don't entirely
understand, I'll try to summarise once I've figured out quite what I
need/want to do.

++L

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)

[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)

[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)

[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)

[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

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]

> 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]

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]

> 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]

> 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)

[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)

[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)

[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)

[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?

[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?