ticki_

4 ms·

1.
Fearless concurrency with hazard pointers(ticki.github.io)
2 points by ticki_ 9y ago|0 comments
2.
by ticki_ 9y ago
> The first section in the README is called "Design goals", with 13 items. None of them is "data integrity", and none of them even talks about validating the data or handling any failures aside from power loss. Fair e
3.
by ticki_ 9y ago
With modern hard disks, no. They work in sectors.
4.
by ticki_ 9y ago
Author here. > I don't know if the authors are here, but if they are - would you comment on fragmentation and the dangers of growing a filesystem past 95-98% full ? Fragmentation isn't an issue in TFS, at all. Because it is a c
5.
by ticki_ 9y ago
The data is summed too.
6.
by ticki_ 9y ago
> A good design would look at the state of the art and use the best techniques available. If the aim was research, then try one new thing, not a thousand. That's what it does: It takes from many sources (although mainly ZFS).
7.
by ticki_ 9y ago
I meant ChaCha20 ofc. Well, my points still remains. You need to store IVs/keys/etc. which makes it pretty unsuitable for a file system.
8.
by ticki_ 9y ago
TFS was created to speed up the development. The issue is that following the design specs makes it much slower to implement, and prevents a "natural" development (like, you cannot implement it like a tower, you need every componen
9.
by ticki_ 9y ago
> I understand this filesystem is still nascent, but shouldn't data integrity at least be one of the design goals? What makes you think it isn't? It definitely is. In fact, it borrows several ideas from ZFS wrt/ integrity.
10.
by ticki_ 9y ago
ChaCha2 isn't a block cipher. It's a stream cipher, and would thus require storage of IVs ... which, well, is going to expensive space-wise.
11.
by ticki_ 10y ago
I agree. SipHash is certainly strong if you don't know the key.
12.
by ticki_ 10y ago
If you know the key, it is as weak as it gets (as the paper notes too, you can construct collisions easily if the key is known), so I disagree.
13.
by ticki_ 10y ago
Oh, well. What I think of as "cryptographic hash function" is a function resistent to pre-image attack, second pre-image attack, and collision generation. Neither of those are satisfied by SipHash, and can thus not classify as a c
14.
by ticki_ 10y ago
Please don't. DJB2 is a poor hash function. It's similar to FNV: Entropy only moves upwards, so flipping higher bits doesn't affect lower bits. In other words, you risk mapping `n` and `-n` to the same value under some modulu
15.
by ticki_ 10y ago
No, it's not a cryptographic hash function. It's a MAC function. The paper clearly states that it is not collision resistant.
16.
by ticki_ 10y ago
A lot of stuff. SHA256 is very slow, and that's no surprise. It's cryptographic after all. Here's a small list of usecases for non-cryptographic hash functions: - Checksums and error correction codes, as long as there is no w
17.
by ticki_ 10y ago
In hash tables, you never use cryptographic hash functions. Why? Because they're slower. Take SHA3, which is around 50x slower than SeaHash. That is really really bad for hash tables. When hash collisions happen in hash tables, they&#x
18.
by ticki_ 10y ago
There's a huge difference between cryptographic and non-cryptographic. Note that blake2 has various length, whereas SeaHash is fixed to 64-bit (although I suppose it's not to hard to make a version with bigger length), and thus na
19.
by ticki_ 10y ago
MetroHash's main transformation actually loses entropy, so that's, well, pretty bad. It still passes Smhasher, though.
20.
by ticki_ 10y ago
SeaHash is obviously not cryptographic (nor is SipHash), but I hope it is a secure PRF (i.e. the keys cannot be extracted), and this was the best attack I was able to construct. Still, it isn't a practical attack, but I suppose it is p
21.
by ticki_ 10y ago
BLAKE(2) is a cryptographic hash function, SeaHash is not. Even the fastest implementations of BLAKE only gets around 7.8 cycles/byte (hardware might do it twice as fast). SeaHash gets 0.24 cycles/byte. That's a wide differen