Live data from Hacker News

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

github.com

121–126 of 126 posts

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

#121

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.

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.

i believe it also does not have as many features as btrfs etc

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

#122
The interplanetary file system [1] comes to mind. Not direct comparable to TFS, but its feature set could inspire a local file system, too:

- historic versioning (like in git)

- deduplication

- authenticity through cryptographic hashing like in block chain

- distributed delivery like bit torrent

I don't think, that we need another ZFS or btrfs competitor. Just my 2 cent.

[1] https://ipfs.io/

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

#124
post #113
post #102

Earlier quoted context omitted.

I only have a basic understanding of harddisks/filesystems, but won't that slow down reading/writing on harddisks since the chunks won't be in order and close together?

With modern hard disks, no. They work in sectors.

I suppose you mean SSD disks.

Rotating disks are surely affected by not contiguous operations, even if done with sector granularity.

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

#125

Earlier quoted context omitted.

You're tilting at windmills. Most threads where someone starts something new has someone making similar complaints to the one you're making here. Yet people's behavior doesn't change. And it won't -- it's just too much overhead to avoid the ever-expanding space of products that have the same name.

Yes, but there's at least two other filesystems called TFS as well, per other threads... so even then, it's still overload. If I were releasing something to the public, I would probably namespace or consider something different in this case.

I did. It’s still not synonymous with “popular.”

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

#126
post #65
post #59

Earlier quoted context omitted.

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…

> 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. In the US. In many other countries, it might gain lots of traction.

You guys might want to learn what FIPS-140 actually specifies before deciding it's part of a nefarious plot.

> In many other countries, it might gain lots of traction.

Maybe, with a handful of techno-anarchists impotently shaking their fist at any US originated standard. But 'other' governments and enterprises routinely spec FIPS-140 compliance. For example, in the EU, CWA-14167 is the equivalent standard, but even ENISA acknowledges that FIPS-140 is equivalent, more widely adopted and is a perfectly acceptable alternative.

Post reply on HN