Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TFS: A file system built for performance, space efficiency, and scalability

github.com

Post reply on HN
Print view View original

71–80 of 126 posts

Re: TFS: A file system built for performance, space efficiency, and scalability

#71

Post by zx2c4 »

ticki_ wrote: post #61
zx2c4 wrote: post #40

While there are many good arguments to be made against AES in favor of ARX construction ciphers, the choice of SPECK for this is not okay. The correct choice of an ARX cipher would have been something like ChaCha20 or Salsa20.

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.

Firstly, it's ChaCha20. I don't think anybody in their right mind would advocate a 2 round ChaCha. Secondly, there _are_ steam cipher constructions to achieve the design requirements for something like TFS.

Re: TFS: A file system built for performance, space efficiency, and scalability

#72

Post by dom0 »

joshbaptiste wrote: post #32
Nokinside wrote: post #20

Good luck. There is long road ahead. Both ZFS and Btrfs were initially developed by really high caliber people and experts with good track record. ZFS had five years for full time development until release, next five years to get close to the features and stability that ZFS has now. Btrfs started 10 years ago and it's still trying to catch up.

Exactly, BcacheFS, HAMMER2 are other file-systems that are being worked on by some REALLY good programmers for years and years to come. It seems like a file-system takes longer to stabilize than a kernel.

I've had some discussions with file system developers and a developer of a distributed file system. The sheer number of failure cases that need to be handled, because they are hit in production systems, is simply staggering.

Re: TFS: A file system built for performance, space efficiency, and scalability

#73

Post by dom0 »

bluejekyll wrote: post #70
pas wrote: post #62

Earlier quoted context omitted.

They have full control of that environment though. So they tested it on a few hundred devices, and by that exhausted all the possible configurations. And when all worked, they knew they have a pretty good indicator for successful deployment on all those millions of devices.

Why downplay it? It's an impressive feat, regardless of the differences in target devices. Even with the hardware configurations well known, the fact that it was done at such a large scale successfully means that even unusual edge conditions didn't crop up. This shouldn't be downplayed, it actually speaks to why it's important to have incremental stages of software delivery. First target highly constrained environmen…

It's absolutely an impressive feat to pull this off. But it's not quite the same problem as building a robust general-purpose FS for a diverse ecosystem.

Re: TFS: A file system built for performance, space efficiency, and scalability

#74

Post by dom0 »

fpgaminer wrote: post #66
api wrote: post #52

Earlier quoted context omitted.

At the risk of discussion hijack, what are these arguments? Any links? (I mean on ARX generally. Agree about Speck.)

Compared to AES, ARX ciphers: 1) Are built from constant time operations, which means they are naturally resistant to side channel attacks (timing, cache, power, etc). 2) Are far simpler in their construction. This makes them easier to reason about and analyze. 3) Related to #2, this also makes them really easy to implement, which means less likelihood of some coding mistake. Beyond that, most recent ARX ciphers also…

ARX constructions are also easier to tune for high software performance, and generally don't require special hardware support, because all CPUs already have fast ARX operations built in.

Re: TFS: A file system built for performance, space efficiency, and scalability

#75

Post by snvzz »

This can't be seen as anything else than a research filesystem that tries several new things at once. Doomed from the start.

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.

For actual promising new filesystem efforts I'd be looking at HAMMER2, Tux3 and F2FS.

Re: TFS: A file system built for performance, space efficiency, and scalability

#76

Post by dom0 »

Kubuxu wrote: post #33
legulere wrote: post #7

I do not buy the argument against AES. On both ARM and x86 you have side-channel secure hardware implementations of AES.

Salsa20 and ChaCha20 are faster on modern hardware than built-in AES instructions. AES is just old and complex. As Salsa family and other modern ciphers have shown you don't have to use complex function to achieve security.

This is just plain wrong.

- AES-256-CTR is about ~25 % faster with AES-NI than ChaCha20. The gap widens when we consider their respective AEAD constructions.

- AES construction has had simply different design goals than ChaCha20. Software implementations took the back seat, Hardware impls were important and AES is unproblematic for those.

- AES is arguably a rather conservative design. To some extent even twenty years later.

Re: TFS: A file system built for performance, space efficiency, and scalability

#77

Post by [deleted] »

dap wrote: post #58

I think one of ZFS's most significant contributions was embracing the specific ways in which disks and HBAs often fail and then building mechanisms to ensure data integrity in the face of those failures. Bit rot and phantom writes are the filesystem's problem, even though they're not the filesystem's fault. ZFS did a lot of work to ensure that integrity: storing checksums in parent blocks, storing metadata redundantl…

[deleted]

Re: TFS: A file system built for performance, space efficiency, and scalability

#78

Post by yellowapple »

zx2c4 wrote: post #40

While there are many good arguments to be made against AES in favor of ARX construction ciphers, the choice of SPECK for this is not okay. The correct choice of an ARX cipher would have been something like ChaCha20 or Salsa20.

Out of curiosity, are there specific reasons why Speck is not suitable for this? I'm not familiar with it, so I'm not sure about its pros/cons.

Re: TFS: A file system built for performance, space efficiency, and scalability

#79

Post by dchest »

zx2c4 wrote: post #40

While there are many good arguments to be made against AES in favor of ARX construction ciphers, the choice of SPECK for this is not okay. The correct choice of an ARX cipher would have been something like ChaCha20 or Salsa20.

The choice of algorithm is less baffling than the choice of mode of operation. When designing a new file system, why in world would you use unauthenticated XEX (or XTS) mode instead of an authenticated mode (SIV, HMAC+CTR, ChaCha20-Poly1305, Speck128+CMAC-Speck128 or whatever). It's not like you need a one-to-one block mapping between encrypted and unencrypted data — you design datastructures yourself, it's a new filesystem! Can't they afford additional 16 bytes?

Re: TFS: A file system built for performance, space efficiency, and scalability

#80

Post by hpcjoe »

djsumdog wrote: post #64
deno wrote: post #22

Earlier quoted context omitted.

https://github.com/tsgates/rust.ko#kernel-api-and-abi-stabil...

The unstable Kernel ABI is really interesting. It's one of the reasons we see all these shims between proprietary drivers and the kernel (nvidia/amd), that and licensing of course.

I know this is true on the nvidia side, but I think it is less true on the AMD side [0]. The old AMD drivers may have been like this, but it appears they have changed.

[0] https://github.com/RadeonOpenCompute/ROCm

Post reply on HN