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

91–100 of 126 posts

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

#91

Post by ticki_ »

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…

> 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.

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

#92

Post by ticki_ »

equalunique wrote: post #90

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://github.com/ticki/zfs

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

#93

Post by ticki_ »

zx2c4 wrote: post #71
ticki_ wrote: post #61

Earlier quoted context omitted.

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.

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.

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

#94

Post by ticki_ »

snvzz wrote: post #75

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.

> 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).

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

#95

Post by cmurf »

ticki_ wrote: post #91
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…

> 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.

I can't tell from the code whether this is metadata only checksumming or if data is also checksummed. ZFS and Btrfs checksum both metadata and data.

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

#96

Post by ticki_ »

cmurf wrote: post #95
ticki_ wrote: post #91

Earlier quoted context omitted.

> 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.

I can't tell from the code whether this is metadata only checksumming or if data is also checksummed. ZFS and Btrfs checksum both metadata and data.

The data is summed too.

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

#97

Post by cmurf »

bluejekyll wrote: post #54
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.

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'm not. Not only is the hardware behavior completely knowable and deterministic, but the user is seriously limited in how much they directly affect either the hardware behavior or the filesystem.

Meanwhile commodity hardware will accept a flush to disk command, and return true when it hasn't flushed it to disk. This is done for performance reasons.

I also note that Apple deployed APFS by default only on the most locked down of the two OS's they produce: it's not the default file system on macOS where there's a much wider assortment of user intervention and hardware availability.

And HFS+ had enough of its own issues, hence why it was being replaced, that it's entirely plausible the problems are fewer expressly because of the change in file systems. I imagine their intent and hope was exactly that or why bother?

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

#98

Post by dchest »

ticki_ wrote: post #93
zx2c4 wrote: 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.

On the contrary, it makes it suitable for file systems! File systems are not block devices, they are data structures on top of block devices — it's the job of these data structures to keep stuff, such as data, inodes, and... keys, and IVs, and MACs, checksums, etc.

TFS uses Speck in XEX mode (edit: I just realized you're the author, so you already know that :). tptacek wrote a nice post about it: https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

and I quote:

"If you’re encrypting a filesystem and not disk blocks, still don’t use XTS! Filesystems have format-awareness and flexibility. Filesystems can do a much better job of encrypting a disk than simulated hardware encryption can."

Edit: check out this presentation on how encryption was bolted on ZFS: https://www.youtube.com/watch?v=frnLiXclAMo (slides: https://drive.google.com/file/d/0B5hUzsxe4cdmU3ZTRXNxa2JIaDQ...) It's not perfect, but it provides data authentication by reusing checksum fields for storing MACs.

Edit 2: also check out bcachefs encryption design doc: http://bcachefs.org/Encryption/ (also not perfect, but uses proper AEAD — ChaCha20-Poly1305. I sent some questions and suggestions to the author, but received no reply :/)

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

#99

Post by laumars »

derefr wrote: post #84
dom0 wrote: post #73

Earlier quoted context omitted.

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.

True; and yet, it feels like there is much low-hanging fruit left in filesystens that are just built for specific vertically-integrated use-cases. A NAS hardware-appliance company, for example, could likely pull off something similar to what Apple did, and to great benefit.

This does already happen, albeit it often isn't advertised.

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

#100

Post by ticki_ »

rsync wrote: 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 does cause a slight space overhead (only slight, coming from the fact that metadata of the file is stored in the full form), but it completely eliminates any fragmentation.

Post reply on HN