linux-kernel - Re: POHMELFS high performance network filesystem. Transactions, failover, performance.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080514211919.GA13513@2ka.mipt.ru>
Date:	Thu, 15 May 2008 01:19:19 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Jamie Lokier <jamie@...reable.org>, Sage Weil <sage@...dream.net>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: POHMELFS high performance network filesystem. Transactions, failover, performance.

On Wed, May 14, 2008 at 04:37:20PM -0400, Jeff Garzik (jeff@...zik.org) wrote:
> That said, the biggest distributed systems seem to inevitably grow their 
> own "front end server" layer.  Clients connect to N caching/application 
> servers, each of which behaves as you describe:  the caching/app server 
> connects to the control and data networks, and performs the necessary 
> load/store operations.
> 
> Personally, I think the most simple thing for _users_ is where 
> semi-smart clients open multiple connections to an amorphous cloud of 
> servers, where the cloud is self-optimizing, self-balancing, and 
> self-repairing internally.

Well, that's how things exist today - POHMELFS client connects to number
of servers and can send data to all of them (currently it doest that for
only 'active' server, i.e. that which was not failed, but that can be
trivially changed). It should be extended to receive 'add/remove server
to the group' command and liekly that's all (modulo other todo items
which are not yet resolved). Then that group becomes quorum and client
has to get response from them. Kind of that...

What I do not like, is putting lots of logic into client, like following
inner server state changes (sync/not sync, quorum election and so on).
With above dumb scheme it should not, but some other magic in the server
land will tell client with whom to start working.

-- 
	Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/