Live data from Hacker News

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

github.com

101–110 of 126 posts

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

#101
post #67

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.

I think you think to highly of the btrfs group. There not bad people but Filesystems are HARD to get right and they simply are not in the same league as the zfs developers were. The well known raid 5 issue btrfs had shows a prime example that the btrfs simply is not in the same class as zfs' design. I wouldn't compare the two.

Btrfs started as a free and open source project from day 1, and people started using it from the moment it was merged mainline which was something like a year.

ZFS was started internally at Sun with a bunch of resources dedicate from people who had been involved in and thinking about storage devices and file systems and their myriad problems for a long time well before they started ZFS. And the cat wasn't out of the bag to end users for about 4 years, during which time there wasn't the contributor pile on effect.

Btrfs had to contend with some balancing act of not saying "no thanks" to patches, meanwhile those contributions very likely did clutter up the code every bit as much as allowing the contribution aided in hyping the project rather than turning people away from contributing at all.

As for raid56, ZFS emerged before cluster file systems like Ceph and Gluster were even conceived. The companies that need to store tons of data, and fund various storage related projects don't care nearly as much as they once did about raid56. They can just replicate the data elsewhere using Gluster and if a whole brick, be it XFS or Btrfs implodes, they can just make a new brick and the data gets replicated again.

Anyway, ZFS and Btrfs are really not comparable even though on the surface they seem to do really similar things.

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

#102
post #100
post #68

I searched the github page and this HN comment thread for the string "frag" and got nothing ... 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 ? In the world of ZFS, performance can become significantly degraded with as low as 90% space filled. Further, our experience has been that you can permanently degrade filesyst…

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 cluster-based file system. Essentially that means that files aren't stored contagiously, but instead in small chunks. The allocation is done entirely on the basis of unrolled freelists. This doe…

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?

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

#103
post #91
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…

> 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. For example, it uses parent block checksums like ZFS.

> What makes you think it isn't?

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.

By contrast, in the canonical slide deck on ZFS[1], the first slide talks about "provable end-to-end data integrity". In the paper[2], "design principles" section 2.6 is "error detection and correction".

I'm glad to hear that's also a focus for TFS. With ZFS, the emphasis on data integrity resulted in significant architectural choices -- I'm not sure it's something that can just be bolted on later. As a reader, I wouldn't have assumed TFS had the same emphasis. I think it's pretty valuable to spell this out early and clearly, with details, because it's actually quite a differentiator compared with most other systems.

[1] https://wiki.illumos.org/download/attachments/1146951/zfs_la...

[2] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.184...

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

#104
post #89
post #63

Earlier quoted context omitted.

I don't consider that a bad thing. The project may pick up more contributors down the road — or it might not. Either way, that doesn't speak negatively of the project itself.

yes, true. But for a file system you either need a lot of time or more people.

I certainly agree. I think there are compelling arguments both for keeping the work to a very small handful of people and for spreading the work across many contributors. It seems to be early days for TFS, but so far it looks like an impressive bit of work.

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

#105

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.

High caliber people need to get paid. Sun invested heavily in zfs. No one (and by that I mean organizations with resources) is really giving btrfs much attention.

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

#106
post #100
post #68

I searched the github page and this HN comment thread for the string "frag" and got nothing ... 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 ? In the world of ZFS, performance can become significantly degraded with as low as 90% space filled. Further, our experience has been that you can permanently degrade filesyst…

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 cluster-based file system. Essentially that means that files aren't stored contagiously, but instead in small chunks. The allocation is done entirely on the basis of unrolled freelists. This doe…

> files aren't stored contagiously

I think you mean contiguously.

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

#107
post #92

Is this the TFS that Redox OS is building after falling short on their ZFS goal?

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 component before completion). It was started[1] and got far enough to reading images, but implementing it took ages, so we decided to put it off for now. It is very similar to ZFS. [1] https://githu…

This doesn't quite seem to follow? ZFS's pool model has supported flagged off features for a very long time - isn't the issue more that to do the things ZFS does you need to implement all the other components? And since you're planning to do a lot of what ZFS does...

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

#108
post #93
post #71

Earlier quoted context omitted.

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.

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.

You got to store checksums separate with the data anyways, if you're already doing that storing nonces isn't that big of a deal. bcachefs does it.

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

#109
post #86
post #38

Earlier quoted context omitted.

It's more than just a bad VCS. It's a bad bug tracker, a bad build system and a bad workflow system as well. But yeah, if I wanted a set of three letters than suggested quality and reliability, TFS would be near the bottom of my list.

Actually I am yet to find a CI system that allows the TFS workflow of preventing checkins if the unit tests fail. All the other ones I know require creating scripts that will manage branches and merges into the main branch. On TFS I select a check box and go off doing something else.

The more you discourage checking in the harder merging becomes.

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

#110
post #109
post #86

Earlier quoted context omitted.

Actually I am yet to find a CI system that allows the TFS workflow of preventing checkins if the unit tests fail. All the other ones I know require creating scripts that will manage branches and merges into the main branch. On TFS I select a check box and go off doing something else.

The more you discourage checking in the harder merging becomes.

In some type of enterprise projects I am quite glad that merge never takes place.

I don't want to have a CI build that is green only a few days when all planets are aligned.

Post reply on HN