Re: [9fans] thoughs about venti+fossil
On Tue, 21 Apr 2015, Russ Cox wrote: My paper with Sean Rhea and Alex Pesterev documents the performance effect of double-checking the equality in some detail. https://www.usenix.org/legacy/event/usenix08/tech/full_papers/rhea/rhea.pdf Very nice paper. Specialy from chapter 3. By reading it, my same original question arises again: Foundation’s CAS layer is modeled on the Venti [34] content-addressed storage server, but we have adapted the Venti algorithms for use in a single-disk system and also optionally eliminated the assumption that SHA-1 is free of collisions, producing two operating modes for Foundation: compare-by-hash and compare-by-value. (Page 4) And the question is answered in the paper: While we originally investigated this mode [Compare-by-value] due to (in our opinion, unfounded) concerns about cryptographic hash collisions (see [5, 16] for a lively debate), we were surprised to find that its overall write performance was close to that of compare-by-hash mode, despite the added comparisons. Moreover, compare-by-value is always faster for reads, as naming blocks by their log offsets completely eliminates index lookups during reads. (page 7) (Caveat: in the usual academic tradition, the paper uses Venti to mean the system described in the original paper, not the system in Plan 9 today. The current Plan 9 implementation is much closer to what the paper calls Foundation: Compare by Hash.) New question: and if I compile it with int verifywrites = 1, is it closer to Compare-by-Value? I mean offset as handle. Hope this helps. I wanted to know if the optional compiling with full check was in consideration of people that have concerns about the (in)correctness of compare-by-hash. One can disagree about the risk of using compare-by-hash, but one cannot disagree in the fact that one disagrees. :) I think, everyone should decide himself if he uses compare-as-hash and where he uses it. In some applications I would even take much more risk than compare-by-hash. And I find interesting the experiments with hash functions, including compare-by-hash. I appreciate that the option of compare-by-value is there. Documentation about where compare-by-hash is used, is important in orther that people may decide by themselve. Interesting would also be the possibility of easily changing the hash functions. As you note in the paper, this is important in compare-by-value for increasing performance. The problem I have with compare-by-hash is not only the probability of hash colisions, but that it seems to rely on empirical knowledge about the used hash function. People used to analytical arguments may find empirical arguments and empirical programming gruesome. If the empirical knowledge changes, if one discovers that the used hash function does not distribute homogenously enough its domain in its range, then one will want (specially in the case of compare by hash) to change the hash function with a better one. Trial and error is the empirical method of solving (and making) problems. Rodrigo.
Re: [9fans] test
lol... you shall have the 45 dollars by sundown, they say... On Wed, Apr 22, 2015 at 7:26 PM, Benjamin Huntsman bhunts...@mail2.cu-portland.edu wrote: Nice! From: 9fans-boun...@9fans.net [9fans-boun...@9fans.net] on behalf of Skip Tavakkolian [skip.tavakkol...@gmail.com] Sent: Wednesday, April 22, 2015 11:24 AM To: Fans of the OS Plan 9 from Bell Labs Subject: Re: [9fans] test a kernel may not work, due to unknown trap lack of wifi drivers and other such crap don't feel flaccid, fire up acid debug it yourself, and spare us the yap On Wed, Apr 22, 2015 at 11:03 AM Conor Williams conor.willi...@gmail.com mailto:conor.willi...@gmail.com wrote: the kernel does not work in an internet cafe what shall i do about the internet cafe ignore the kernel ignore the kernel ignore the kernel . . . ad infinium... On Mon, Apr 20, 2015 at 2:16 AM, Shane Morris edgecombe...@gmail.com mailto:edgecombe...@gmail.com wrote: Love the limerick! =P On Mon, Apr 20, 2015 at 11:08 AM, Skip Tavakkolian 9...@9netics.com mailto:9...@9netics.com wrote: please ignore... there was once a mascot named glenda for an operating system that's kinda splenda until, that is, a bunch of kids ripped off its front fenda
Re: [9fans] p9p mouse problem
Hello, On 31 March 2015 at 15:37, Rudolf Sykora rudolf.syk...@gmail.com wrote: I now encounter a problem with my mouse in plan9port. Every now and then it happens that my left button starts to behave as the right button. What helps is pressing a ctrl key on the keyboard: immediately after that things are ok again for a while. I now see this happen on several machines... (always on Slackware) Hasn't anybody else seen this? Or does anybody have a clue about what could cause it? (It only happens in p9p programs [sam, acme], never in linux ones.) Ok, I still haven't passed over the problem. As I see it on two individual machines with a common system, I think it might be system related, slackware 14.1. I could try and upgrade some packages to the current slackware branch (i.e. substitute probably some X packages) if I only could guess which part of the system could possibly be responsible. Is there anybody who could guess? Thanks Ruda
Re: [9fans] p9p mouse problem
Hi Ruda, On Thu, Apr 23, 2015, at 11:38 AM, Rudolf Sykora wrote: On 31 March 2015 at 15:37, Rudolf Sykora rudolf.syk...@gmail.com wrote: I now encounter a problem with my mouse in plan9port. Every now and then it happens that my left button starts to behave as the right button. What helps is pressing a ctrl key on the keyboard: immediately after that things are ok again for a while. I believe I had this problem on FreeBSD. I have setxkbmap -option grp:shifts_toggle,ctrl:nocaps us,rs(latin) in my .xinitrc, and when I press left shift key, left button starts to behave as right button. If I run: setxkbmap -option us,rs(latin) setxkbmap -option grp:menu_toggle,ctrl:nocaps us,rs(latin) Acme behaves normally. Check out this bug report (I'm not sure why it was marked Invalid): https://bitbucket.org/rsc/plan9port/issue/135/xkboptions-with-shift-both_capslock_cancel Regards, Bojan
