[gentoo-user] Re: File system testing

[James]

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


> > Distributed File Systems (DFS):

> > Local (Device) File Systems LFS:

> Is my understanding correct that the top list all require one of
> the bottom  list?
> Eg. the "clustering" FSs only ensure the files on the LFSs are
> duplicated/spread over the various nodes?

> I would normally expect the clustering FS to be either the full layer
> or a  clustered block-device where an FS can be placed on top.

I have not performed these installation yet. My research indicates
that first you put the Local FS on the drive, just like any installation
of Linux. Then you put the distributed FS on top of this. Some DFS might
not require a LFS, but FhGFS does and does HDFS. I will not acutally
be able to accurately answer your questions, until I start to build
up the 3 system cluster. (a week or 2 away) is my best guess.


> Otherwise it seems more like a network filesystem with caching
> options (See  AFS).

OK, I'll add AFS. You may be correct on this one  or AFS might be both.

> I am also interested in these filesystems, but for a slightly different
> scenario:

Ok, so I the "test-dummy-crash-victim" I'd be honored to have, you,
Alan, Neil, Mic  etc etc back-seat-0drive on this adventure! (The more 
I read the more it's time for burbon, bash, and a  bit of cursing
to get started...)


> - 2 servers in remote locations (different offices)
> - 1 of these has all the files stored (server A) at the main office
> - The other (server B - remote office) needs to "offer" all files
> from serverA  When server B needs to supply a file, it needs to
> check if the local copy is still the "valid" version.
> If yes, supply the local copy, otherwise download
> from server A. When a file is changed, server A needs to be updated.
> While server B is sharing a file, the file needs to be locked on server A
> preventing simultaneous updates.

OOch, file locking (precious tells me that is alway tricky).
(pist, systemd is causing fits for the clustering geniuses;
some are espousing a variety of cgroup gymnastics for phantom kills)
Spark is fault tolerant, regardless of node/memory/drive failures
above the fault tolerance that a file system configuration many support.
If fact, files lost can be 'regenerated' but it is computationally
expensive. You have to get your file system(s) set up. Then install
mesos-0.20.0 and then spark. I have mesos mostly ready. I should
have spark in alpha-beta this weekend. I'm fairly clueless on the 
DFS/LFS issue, so a DFS that needs no LFS might be a good first choice
for testing the (3) system cluster.


> I prefer not to supply the same amount of storage at server B as
> server A has. The remote location generally only needs access to 5% of
> the total amount of files stored on server A. But not always the same 5%.
> Does anyone know of a filesystem that can handle this?

So in clustering, from what I have read, there are all kinds of files
passed around between the nodes and the master(s). Many are critical
files not part of the application or scientific calculations. 
So in time, I think in a clustering evironment, all you seek is
very possible, but it's a hunch, gut feeling, not fact. I'd put
raid mirros underdneath that system, if it makes sense, for now,
or just dd the stuff with a script of something kludgy (Alan is the
king of kludge....)

On gentoo planet one of the devs has "Consul" in his overlays. Read
up on that for ideas that may be relevant to what you need.


> Joost

James