looks like a one man/woman show. the graphs show most of the activity only by one contributor. :(
TFS: A file system built for performance, space efficiency, and scalability
51–60 of 126 posts
Re: TFS: A file system built for performance, space efficiency, and scalability
#52While 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.
At the risk of discussion hijack, what are these arguments? Any links?
(I mean on ARX generally. Agree about Speck.)
Re: TFS: A file system built for performance, space efficiency, and scalability
#53I 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.
Salsa20 and ChaCha20 aren't FIPS140-2 certified (that I'm aware of or can find documented) which is pretty much a basic requirement at this point for anything in the enterprise.
Re: TFS: A file system built for performance, space efficiency, and scalability
#54Good 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.
Has anyone done an analysis of the number of logic bugs in ZFS and btrfs vs. memory safety or concurrent updates to memory, etc.?
Also, I'll point out that Apple just dropped a new FS on millions of devices, with no issues... that was developed in 3 or 4 years. I'm still blown away that they pulled that off.
Re: TFS: A file system built for performance, space efficiency, and scalability
#55Improved caching TFS puts a lot of effort into caching the disk to speed up disk accesses. It uses machine learning to learn patterns and predict future uses to reduce the number of cache misses. See that does sound like a good idea - I've always observed HDDs with an SSD cache to have a phenomanly useless caching system
I'm not a big fan of putting machine learning into a file system. Usually you can't understand why a machine learning algorithm is doing what it's doing, and I would be worried about a production server suddenly having massively different performance because the cache learning algorithm started doing something differently. Interesting idea, but I would want to battle test it before I bought in.
It's impossible to tell what's going on nowdays with optimizing compilers, memory overcommitment, hardware branch predictions, power saving measures, etc.
Re: TFS: A file system built for performance, space efficiency, and scalability
#56Improved caching TFS puts a lot of effort into caching the disk to speed up disk accesses. It uses machine learning to learn patterns and predict future uses to reduce the number of cache misses. See that does sound like a good idea - I've always observed HDDs with an SSD cache to have a phenomanly useless caching system
Isn't their lunch being eaten by intel optane?
Re: TFS: A file system built for performance, space efficiency, and scalability
#57Earlier quoted context omitted.
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.
Salsa20 and ChaCha20 aren't FIPS140-2 certified (that I'm aware of or can find documented) which is pretty much a basic requirement at this point for anything in the enterprise.
And they probably won't for political reasons. Salsa20 was created by DJB who has previously fought with US Gov against encryption export ban and also they have their own suits they prefer you to use (for their own reasons).
Here is a reason why you can't trust US Gov for creating secure encryption: https://en.wikipedia.org/wiki/Dual_EC_DRBG
Re: TFS: A file system built for performance, space efficiency, and scalability
#58I 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 redundantly, fixing bad copies with the good ones when corruption is detected, and scrubbing. In many filesystems still in use today, applications can easily receive garbage data from the system.
I understand this filesystem is still nascent, but shouldn't data integrity at least be one of the design goals?
Re: TFS: A file system built for performance, space efficiency, and scalability
#59Earlier quoted context omitted.
Salsa20 and ChaCha20 aren't FIPS140-2 certified (that I'm aware of or can find documented) which is pretty much a basic requirement at this point for anything in the enterprise.
And they probably won't for political reasons. Salsa20 was created by DJB who has previously fought with US Gov against encryption export ban and also they have their own suits they prefer you to use (for their own reasons). Here is a reason why you can't trust US Gov for creating secure encryption: https://en.wikipedia.org/wiki/Dual_EC_DRBG
It doesn't matter if I trust or distrust the US government for creating secure encryption. There are laws in place across a plethora of industries REQUIRING FIPS140-2. If you want to do business in the US, it's a basic requirement.
At the end of the day the odds of this filesystem gaining any traction are basically 0. I'm just pointing out that not supporting an encryption algorithm that can meet the FIPS requirement makes it basically a non-starter for any commercial application.
Re: TFS: A file system built for performance, space efficiency, and scalability
#60Earlier quoted context omitted.
ChaCha20 would be the right choice here, not SPECK.
Or if they really want a lightweight cipher with a small block size, they should consider SPARX, especially since a Rust implementation is readily available: https://github.com/jedisct1/rust-sparx
Has anyone analyzed SPARX other than the authors? It seems a little early to recommend its use.