[gentoo-user] Re: File system testing

[James]

J. Roeleveld <joost <at> antarean.org> writes:


> Out of curiosity, what do you want to simulate?

subsurface flows in porous medium. AKA carbon sequestration
by injection wells. You know, provide proof that those
that remove hydrocarbons and actuall put the CO2 back
and significantly mitigate the effects of their ventures.

It's like this. I have been stuggling with my 17 year old "genius"
son who is a year away from entering medical school, with
learning responsibility. So I got him a hyperactive, highly
intelligent (mix-doberman) puppy to nurture, raise, train, love
and be resonsible for. It's one genious pup, teaching another
pup about being responsible.

So goes the earl_bidness.......imho.



 
> > Many folks are recommending to skip Hadoop/HDFS all  together

> I agree, Hadoop/HDFS is for data analysis. Like building a profile
> about people based on the information companies like Facebook,
> Google, NSA, Walmart, Governments, Banks,.... collect about their
> customers/users/citizens/slaves/....

> > and go straight to mesos/spark. RDD (in-memory)  cluster
> > calculations are at the heart of my needs. The opposite end of the
> > spectrum, loads of small files and small apps; I dunno about, but, I'm all
> > ears.
> > In the end, my (3) node scientific cluster will morph and support
> > the typical myriad  of networked applications, but I can take
> > a few years to figure that out, or just copy what smart guys like
> > you and joost do.....
>  
> Nope, I'm simply following what you do and provide suggestions where I can.
> Most of the clusters and distributed computing stuff I do is based on
> adding machines to distribute the load. But the mechanisms for these are >
implemented in the applications I work with, not what I design underneath.

> The filesystems I am interested in are different to the ones you want.

Maybe. I do not know what I want yet. My vision is very light weight 
workstations running lxqt (small memory footprint) or such, and a bad_arse
cluster for the heavy lifting running on whatever heterogenous resoruces I
have. From what I've read, the cluster and the file systems are all
redundant that the cluster level (mesos/spark anyway) regardless of one any
give processor/system is doing. All of Alans fantasies (needs) can be
realized once the cluster stuff is master. (chronos, ansible etc etc).

> I need to provided access to software installation files to a VM server
> and access to documentation which is created by the users. The
> VM server is physically next to what I already mentioned as server A.
> Access to the VM from the remote site will be using remote desktop
> connections.  But to allow faster and easier access to the
> documentation, I need a server B at the remote site which functions as
> described.  AFS might be suitable, but I need to be able to layer Samba
> on top of that to allow a seamless operation.
> I don't want the laptops to have their own cache and then having to
> figure out how to solve the multiple different changes to documents
> containing layouts. (MS Word and OpenDocument files).

Ok so your customers (hperactive problem users) inteface to your cluster
to do their work. When finished you write things out to other servers
with all of the VM servers. Lots of really cool tools are emerging
in the cluster space.

I think these folks have mesos + spark + samba + nfs all in one box. [1]
Build rather than purchase? WE have to figure out what you and Alan need, on
a cluster, because it is what most folks need/want. It the admin_advantage
part of cluster. (There also the Big Science (me) and Web centric needs.
Right now they are realted project, but things will coalesce, imho. There is
even "Spark_sql" for postgres admins [2].

[1]
http://www.quantaqct.com/en/01_product/02_detail.php?mid=29&sid=162&id=163&qs=102

[2] https://spark.apache.org/sql/


> > > We use Lustre for our high performance general storage. I don't
> > > have any numbers, but I'm pretty sure it is *really* fast (10Gbit/s
> > > over IB sounds familiar, but don't quote me on that).
> >
> > AT Umich, you guys should test the FhGFS/btrfs combo. The folks
> > at UCI swear about it, although they are only publishing a wee bit.
> > (you know, water cooler gossip)...... Surely the Wolverines do not
> > want those californians getting up on them?

> > Are you guys planning a mesos/spark test?

> > > > Personally, I would read up on these and see how they work. Then,
> > > > based on that, decide if they are likely to assist in the specific
> > > > situation you are interested in.

> > It's a ton of reading. It's not apples-to-apple_cider type of reading.
> > My head hurts.....

> Take a walk outside. Clear air should help you with the headaches :P

Basketball, Boobs and Burbon use to work quite well. Now it's mostly
basketball, but I'm working on someone "very cute"......

> > I'm leaning to  DFS/LFS
> > (2)  Luster/btrfs      and     FhGFS/btrfs

> I have insufficient knowledge to advise on either of these.
> One question, why BTRFS instead of ZFS?

I think btrfs has tremendous potential. I tried ZFS a few times,
but the installs are not part of gentoo, so they got borked
uEFI, grubs to uuids, etc etc also were in the mix. That was almost
a year ago. For what ever reason the clustering folks I have
read and communicated with are using ext4, xfs and btrfs. Prolly
mostly because those are mostly used in their (systemd) inspired)
distros....?

 
> My current understanding is: - ZFS is production ready, but due to
> licensing issues, not included in the kernel - BTRFS is included, but
> not yet production ready with all planned features.

Yep. the license issue with ZFS is a real killer for me. Besides,
as an old state-machine, C hack, anything with B-tree is fabulous.
Prejudices? Yep, but here, I'm sticking with my gut. Multi port
ram can do mavelous things with Btree data structures. The 
rest will become available/stable. Simply, I just trust btrfs, in
my gut.

  
> For me, Raid6-like functionality is an absolute requirement and latest I >
know is that that isn't implemented in BTRFS yet. Does anyone know when 
> that will be implemented and reliable? Eg. what time-frame are we
> talking about?


Now we are "communicating"! We have different visions. I want cheap,
mirrored HD on small numbers of processors (less than 16 for now).
I want max ram of the hightest performance possilbe. I want my reduncancy
in my cluster with my cluster software deciding when/where/how-often
to write out to HD. If the max_ram is not enought, then SSD will 
be between the ram and HD. Also, know this. The GPU will be assimilated 
into the processors, just like the FPUs were, some decade ago. Remember
the i386 and the i387 math coprocessor chip? The good folks at opengl,
gcc (GNU) and others will soon (eventually?) give us compilers to
automagically use the gpu (and all of that blazingly fast ram therein,
as slave to Alan admin authority (some bullship like that).


So, my "Epiphany" is this. The bitches at systemd are to renamed
"StripperD", as they will manage the boot cycle (how fast you can
go down (save power) and come back up (online). The Cluster
will rule off of your hardware, like a "Sheilk" "the ring that rules 
them all" be  the driver of the gabage collect processes. The cluster
will be like the "knights of the round table"; each node helping, and
standing for those other nodes (nobles) that stumble, always with
extra resources, triple/quad redundancy and solving problems
before that kernel based "piece of" has a chance to anything
other than "go down" or "Come up" online.

We shall see just who the master is of my hardawre!
The sadest thing for me is that when I extolled about billion
dollar companies corrupting the kernel development process, I did
not even have those {hat wearing loosers} in mind. They are 
irrelevant. I was thinking about those semiconductor companies.
You know the ones that accept billions of dollars for the NSA
and private spoofs to embed hardware inside of hardware. The ones
that can use "white noise" as a communications channel. The ones
that can tap a fiber optic cable, with penetration. Those are
the ones to focus on. Not a bunch of "silly boyz"......

My new K_main{} has highlighted a path to neuter systemd.
But I do like how StripperD moves up and down, very quickly.

Cool huh? 
It's PARTY TIME!

> Joost
James