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: <Pine.LNX.4.64.0805141247180.23143@cobra.newdream.net>
Date:	Wed, 14 May 2008 13:00:05 -0700 (PDT)
From:	Sage Weil <sage@...dream.net>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Evgeniy Polyakov <johnpol@....mipt.ru>,
	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, 14 May 2008, Jeff Garzik wrote:
> > Similarly, if only 1 out of 3 replicas is surviving, most people want to be
> > able to read their data, while Paxos demands a majority to ensure it is
> > correct.
> 
> This isn't necessarily true -- it's quite easy for most applications to come
> up with an alternate method for ensuring correctness of retrieved data, if one
> assumes Paxos consensus was achieved during the write-data phase earlier in
> time.  Checksumming is a common solution, but not the only one.  Domain- or
> app-specific solution, as noted, of course.

You mean if, say, some verifiable metadata or a trusted third party stores 
that checksum?  Sure.  This is just pushing the what-has-committed 
information to some other party, though, who will presumably face the same 
problem of requiring a majority for verifiable correctness.  This is more 
or less what most people do in practice... using Paxos for critical state 
and piggybacking the rest of the system's consistency off of that.

> > (This is why Paxos is typically used only for critical cluster
> > configuration/state, not regular data.)
> 
> Yep, I'm working on a config daemon a la Chubby or zookeeper, based on Paxos,
> that does just this.  :)

Cool.  Do you have a URL?  I'd be interested in seeing how you diverge 
from classic paxos.  For Ceph's monitor daemon, the main requirements 
(besides strict correctness guarantees) were scalable (distributed) read 
access, and a history of state changes.  Nothing too unusual.

sage
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ