12 ms·
TFS: A file system built for performance, space efficiency, and scalability
- grub5000 9y agoImproved 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
- Someone 9y agoCertainly a good idea, _if_ you have unlimited resources. Without that, I think one should focus on getting the on disk structures right and the code manipulating them solid. That is enough of a challenge.
- primer42 9y agoI'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.
- paulddraper 9y agoIt's impossible to tell what's going on nowdays with optimizing compilers, memory overcommitment, hardware branch predictions, power saving measures, etc.
- simooooo 9y agoIsn't their lunch being eaten by intel optane?
- visarga 9y agoSeems exciting, but popularizing a new file system is extremely hard.
- tracker1 9y ago"Team Foundation Server" (Microsoft's version control server) is what goes through my mind... poor choice of naming...
- solatic 9y agoThe readme also alludes to a file system by terminalcloud which is also apparently named TFS, and doesn't explain what the T is supposed to stand for. Really poor choice of name. If they wanted a modular replacement for ZFS then call it MFS or ModFS or something...
- jasode 9y agoI read the TFS github landing page and it didn't explain what the 'T' stood for. I then noticed the author's name is "Ticki"[1]. Therefore, I can only guess that TFS stands for "Ticki's File System". [1]http://ticki.github.io/about/ http://ticki.github.io/about/
- deno 9y agoSo you have to add “fs” or “filesystem“ to your search queries, or not even that if the rest of the query gives sufficient context. Everyone makes name conflicts in independent domains to be a much bigger problem than they are in reality. There’s Amazon rainforest, Amazon the ecommerce website, and Amazon the cloud company. How often do you have any problem differentiating between them?
- 9y ago
- inlineint 9y agoI wonder would it be possible to use it somehow with Linux (in kernel space, not with fuse, because fuse has work slower because of necessary context switches from kernel to user space). I mean it is interesting can a wrapper kernel module be written for interfacing with Rust code, or there are some obstacles that would prevent from doing it efficiently.
- deno 9y agohttps://github.com/tsgates/rust.ko#kernel-api-and-abi-stability https://github.com/tsgates/rust.ko#kernel-api-and-abi-stabil...
- djsumdog 9y agoThe 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.
- hpcjoe 9y agoI 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 https://github.com/RadeonOpenCompute/ROCm
- deleted 9y ago[deleted]
- hestefisk 9y agoGood luck developing something better and more stable than zfs...
- legulere 9y agoI do not buy the argument against AES. On both ARM and x86 you have side-channel secure hardware implementations of AES.
- beefhash 9y agoI assume they're targeting more than just ARM and x86, given they're talking about "truely portable AES implementations" in the README[1]. That said, I'm very inclined to distrust a very young cipher... released by the NSA, no less[2]. Which is an add-rotate-xor cipher[2], for which we already have the more reviewed ChaCha20[3], suggested for TLS 1.3[4]. [1] https://github.com/redox-os/tfs/blob/master/README.rst#faq https://github.com/redox-os/tfs/blob/master/README.rst#faq [2] https://eprint.iacr.org/2013/404 https://eprint.iacr.org/2013/404 [3] https://cr.yp.to/chacha/chacha-20080128.pdf https://cr.yp.to/chacha/chacha-20080128.pdf [4] https://tools.ietf.org/html/rfc7905 https://tools.ietf.org/html/rfc7905
- nightcracker 9y agoChaCha20 would be the right choice here, not SPECK.
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- jedisct1 9y agoOr 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 https://github.com/jedisct1/rust-sparx
- jstarks 9y agoHas anyone analyzed SPARX other than the authors? It seems a little early to recommend its use.
- desdiv 9y agoIs the choice of SPECK a serious decision or is it some kinda of a political/satire/parody thing?
- gpm 9y agoI'm fairly sure it's serious, though if you look at the specification it's made to be easily swapable. It's specified by a 'vdev', which is a layer on top of the core filesystem specified by a 16bit int. You could easily make another for ChaCha20 and use that instead (or also).
- edward_rolf 9y ago>The system will never enter an inconsistent state (unless there is hardware failure), meaning that unexpected power-off won't ever damage the system. What is the difference here between a hardware failure and a unexpected power failure?
- nbevans 9y agoHardware failures could imply "flipped bits" (depending on failure mode) whereas loss of power should just mean "truncated bits".
- deleted 9y ago[deleted]
- jsiepkes 9y agoAnd what about a kernel panic?
- eximius 9y agoYea, I'd like a little more detail on this point too.
- zitterbewegung 9y agoUnexpected shutdown would just use the features of a Journaling file system to recover the data. A hardware failure would be a Raid controller failure or malfunction or a hard drive / SSD failure .
- jstimpfle 9y agoThe section "2. Hardware Assumptions" in the Sqlite docs here has some interesting related stuff: https://www.sqlite.org/atomiccommit.html https://www.sqlite.org/atomiccommit.html
- gpm 9y agoI think the spec answers your question here TFS provides following guarantees: - Unless data corruption happens, the disk should never be an inconsistent state \footnote{TFS achieves this without using journaling or a transactional model.}. Poweroff and the alike should not affect the system such that it enters an invalid or inconsistent state. Provided that following premises hold: - Any sector (assumed to be a power of two of at least \minimumsectorsize bytes) can be read and written atomically, i.e. it is never partially written, and interrupting the write will never render the disk in a state in which it not already is written or retaining the old data. Data corruption can break these guarantees or premises, and TFS encompasses certain measures against such corruption, but they are strictly speaking heuristic, like any error detection and correction method, as the damage could be across all the disks.
- Nokinside 9y agoGood 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.
- X86BSD 9y agoI 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.
- eriknstr 9y agoI use ZFS under FreeBSD but I am wondering what the future of ZFS looks like. I went to the OpenZFS website (http://open-zfs.org/wiki/Main_Page http://open-zfs.org/wiki/Main_Page) to try and get a feel for the amount of work currently going on. They have some videos and slides, they have a mailing list. The mailing list is mostly full of messages via GitHub but at least that lead me to https://github.com/openzfs/openzfs https://github.com/openzfs/openzfs which I was previously unaware of and which I had not found when trying to look for an OpenZFS specific repository. As far as I have come to understand, the goal of the OpenZFS project is to merge changes made to ZFS by Illumos, FreeBSD, ZFS-on-Linux and other projects. Their videos might answer this but I wish their website had a clear and simple overview of what has been done. Most of what I can find on their wiki is various ideas for things that they want to do, but I can't know if that means that the OpenZFS project is mostly talk and not so much action, or if it's just that they have done a lot of those things but because they are busy doing they don't have time to write about it. Could be that they have some pages on the wiki I haven't seen also but in that case I think it should be organized better. I know that Joyent picked up several highly skilled software engineers and programmers that used to work for Sun, and that their SmartOS operating system builds on code descendant from OpenSolaris and that ZFS is as integral on SmartOS as it was on Solaris, perhaps even more so on SmartOS. I have not seen mention of SmartOS on the OpenZFS wiki though. All in all I feel that ZFS is still being actively developed and maintained by many people. But to what extent they are able to cooperate as much as a lot of them seem to want to I would like to know. It would be a shame if btrfs overtook ZFS simply because the development of ZFS was too fragmented :/
- ysleepy 9y agoWhat cipher block mode is used with SPECK? Block based disk encryption is complicated to get right due to replay attacks of blocks over time and IV issues. There are established best-practice compromises with AES, but I dont know if they apply to other block ciphers and doubt they are tested.
- tptacek 9y agoXEX, unfortunately. That's a mistake. Unauthenticated tweakable wide-block cipher modes are designed for simulated hardware disk encryption. That's not what an encrypted filesystem is: a filesystem knows where files begin and end, and has space for metadata. Filesystem encryption should use authenticated encryption.
- agumonkey 9y agoIIRC disk controllers used "ML" since quite a time already.
- zx2c4 9y agoWhile 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.
- api 9y agoAt the risk of discussion hijack, what are these arguments? Any links? (I mean on ARX generally. Agree about Speck.)
- fpgaminer 9y agoCompared 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 have a few other advantages over AES. For example, Threefish has a built-in tweak field, which makes using it infinitely easier in practice. EDIT: In case you're hungry for more detailed explanations, I highly recommend reading the papers for Salsa/Chacha and Threefish. They're very well written, easy to understand even if you don't have a lot of experience with cryptography, and they have sections that explain the design decisions in enlightening detail.
- dom0 9y agoARX 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.
- tptacek 9y agoThat's true, but: * The CPUs that have better-than-ARX (like, fast constant time multiplication) can do better than ARX * Fast ARX ciphers are still slower than Intel AES hardware. I like Salsa/ChaCha more than AES, but there's a reason AES is so popular, and it's not incompetence or a conspiracy.
- je42 9y agolooks like a one man/woman show. the graphs show most of the activity only by one contributor. :(
- ovao 9y agoI 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.
- je42 9y agoyes, true. But for a file system you either need a lot of time or more people.
- ovao 9y agoI 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.
- dap 9y agoI 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?
- deleted 9y ago[deleted]
- ticki_ 9y ago> 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.
- cmurf 9y agoI 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.
- ticki_ 9y agoThe data is summed too.
- dap 9y ago> 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_last.pdf https://wiki.illumos.org/download/attachments/1146951/zfs_la... [2] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.184.3704&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.184...
- rsync 9y agoI 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 filesystem performance by churning the usage above 95% for any significant amount of time. Which is to say, even if you reduce usage back down to 80%, the zpool maintains poor performance until it is destroyed and recreated. This is exactly what you would expect to see with a fragmenting filesystem that has no defrag tool. Unfortunately, creating a defrag tool for ZFS is a very daunting technical hurdle and it appears that nobody is interested in pursuing it. How does TFS behave ? Does it have, or do you plan for it to have, a defrag utility ?
- ticki_ 9y agoAuthor 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.
- snvzz 9y agoThis 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.
- ticki_ 9y ago> 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).
- floydtom2 9y agoControl devices remotely hack + Burner Numbers hack + Verified Paypal Accounts hack + Any social media account hack + Android & iPhone Hack + server crashed hack + Text message interception hack + Twitters hack + Skype hack + Credit cards hacker + We can drop money into bank accounts. + credit score hack + blank credit card sale + Hack and use Credit Card to shop online + Monitor any phone and email address + Tap into anybody's call and monitor their conversation CONTACT:ftom9856 via kik Or email blackspothack@gmail. com
- equalunique 9y agoIs this the TFS that Redox OS is building after falling short on their ZFS goal?
- ticki_ 9y agoTFS 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 https://github.com/ticki/zfs
- XorNot 9y agoThis 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...
- deleted 9y ago[deleted]
- Handgemenge 9y agoThe 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/ https://ipfs.io/