EUREKA - was the 'why' of pseudofs

[Bill Hacker]

Matthew Dillon wrote:

There are several reasons for using PFSs.


EUREKA!

Matt - you've re-invented Ramphotyphlops braminus:

Weigh this:


PFS = Parthenogenetic File System


hammer pfs-master  = select a host.

hammer pfs-slave   = induce ovulation.

hammer mirror-copy = self-inseminate the egg, provide nutrients to
 grow a clone with the instincts of the parent.

hammer mirror-stream = continue growing/educating the child.

   While growing, deny it independence.
   (parent has r/w, others can see but not touch = no deviation)


hammer pfs-upgrade = hatch the egg, grant adulthood.


HAMMER fs structure - DNA if you will - must be precisely replicated in 
core form before any body-mass (files) save its own 'schema' can be 
added. Notochordata grow the spinal chord, THEN 'bud' the organs. The 
nerve-'tree' remains connected, trunked back to the brain, enforces 
order, reports environment.


Snapshotting, reblocking, pruning are comparable to our nightly sort, 
merge, index, and re-write of short-term memory to long-term memory.


So we're not really growing a Ramphotyphlops here.

We're growing the indexed storage portion and the storage/retrieval 
mechanism  . of a brain.


Proven pattern among Odontata, too:

http://ecoevo.uvigo.es/Olalla/index_en.htm

.. so this file system could live a very, very long time..

Wonder how long before it grows wings

...or an appetite...

:-)

Bill

Fwd: EUREKA - was the 'why' of pseudofs

[Colin Adams]

-- Forwarded message --
From: Colin Adams colinpaulad...@googlemail.com
Date: 2009/2/18
Subject: Re: EUREKA - was the 'why' of pseudofs
To: Bill Hacker w...@conducive.org


2009/2/18 Bill Hacker w...@conducive.org:
 Proven pattern among Odontata, too:

 http://ecoevo.uvigo.es/Olalla/index_en.htm

That should be Odonata (= tooth-jawed) (Dragonflies and damselflies to
the rest of you - i.e Bill is trying to make the posting relevant to
DragonFly BSD).

Incidentally, I looked at that web page, and by a curious coincidence,
I had an email this week from the guy she mentions as her PhD
supervisor - as he is the webmaster of the Worldwide Dragonfly
Association, and I was complaining about broken links.

Anyway, thanks for the link. I knew about the parthogenetic population
of Ischnura hastata on the Azores, but I didn't know there was a
downloadable thesis on the sunject, so I've just grabbed it.

It's really time I actually started using DragonFly (perhaps to port
GHC to it, as I am programming in Haskell these days). Is it available
64-bit yet?

Re: Fwd: EUREKA - was the 'why' of pseudofs

[Bill Hacker]

Colin Adams wrote:

-- Forwarded message --
From: Colin Adams colinpaulad...@googlemail.com
Date: 2009/2/18
Subject: Re: EUREKA - was the 'why' of pseudofs


2009/2/18 Bill Hacker w...@conducive.org:

Proven pattern among Odontata, too:

http://ecoevo.uvigo.es/Olalla/index_en.htm


That should be Odonata (= tooth-jawed) (Dragonflies and damselflies to
the rest of you - i.e Bill is trying to make the posting relevant to
DragonFly BSD).


Thanks - typing and proofing was easier when I still had the sight of
two eyes...

;-)



Incidentally, I looked at that web page, and by a curious coincidence,
I had an email this week from the guy she mentions as her PhD
supervisor - as he is the webmaster of the Worldwide Dragonfly
Association, and I was complaining about broken links.



'small world..'


Anyway, thanks for the link. I knew about the parthogenetic population
of Ischnura hastata on the Azores, but I didn't know there was a
downloadable thesis on the sunject, so I've just grabbed it.

It's really time I actually started using DragonFly (perhaps to port
GHC to it, as I am programming in Haskell these days). Is it available
64-bit yet?



Dunno. We've been 'greening down' to VIA CPU for lack of enough UPS
budget in the Data Centre, and their first 64-bit is still scarce.

But ISTR at least a couple of the devel team run on AMD-64..

What I've got to sort is whether/how soon DFY uses/will use the in-built
VIA hardware encryption engine.

I've seen tests showing it to need only 5% of the resources a
general-purpose CPU needs for the same encryption/decryption workload,
ergo letting the lowly VIA punch well above its weight in an
increasingly ssh/TLS'ed world. IF the algorithms it supports are among
the choices, anyway...

Meanwhile - and I expect this was already well-known among the
cognoscenti - scp'ing vs mirror-copy'ing from a *single* as-current PFS
snapshot, shows hammerfs on a laptop - especially one that has slept
through four days worth of cron's reblock-prune, can 'punch above its
weight'also. But in a different way.

For kicks, I've scp'ed from the root of /pfs (/pfs/usr ...) as well as
from the mount-point of each individual (virtual) mount (/usr..).

Naturally, scp -r is expanding the snapshots retained over a four day
period.

Predictable result?

- Four copies on the target from /pfs/usr et al, PLUS the ONE copy from
/usr.  Same files, near-zero actually changed, save for /var/log.  But
scp -r cannot know that there was no change, so

Five times the storage space needed on the target as on the original.

Glad it was not three weeks...

If a man won't take fishing instruction, just let him figure out on his
own how to fish

.. and he'll much better appreciate a fish 'n chips shop...

;-)

Bill