7 ms·
Removing fsync from our local storage engine
- bawolff 4mo agoAm i understanding correctly that you are just targeting consistency and not durability?
- zzsheng 4mo agoAuthor here. This is not a general argument against fsync; the design depends on SSD-only deployment, preallocated files, O_DIRECT, single-key atomicity, and device write guarantees.
- 100ms 4mo agoYour approach looks interesting but I was curious when you talk about path-based splitting for ART, do you literally mean always on "/"? I know S3 directory buckets always use /, but the classical S3 model had no natural separator character and I was wondering if supporting those styles of prefix or custom delimiter queries suffered any impediment in your approach. Bookmarked your whole blog for later consumption, interesting stuff!
- deleted 4mo ago[deleted]
- thomas_fa 4mo agoThanks for the encouragement! Another author here. Yes, if you are interested you can check our another blog [1] for the internal storage engine. Yes, we are limiting the delimeter to "/", to better support posix FS semantics. I have just finished the fs feature branch which has passed all posix fstests [2]. [1] https://fractalbits.com/blog/metadata-engine-for-our-object-storage-from-lsm-tree-to-fractal-art/ https://fractalbits.com/blog/metadata-engine-for-our-object-... [2] https://github.com/pjd/pjdfstest https://github.com/pjd/pjdfstest
- atombender 4mo agoI'm surprised none of the design decisions considered an indirection between the folder tree structure and the actual files. For example, if you map folders like /foo and /foo/bar to numeric IDs, then each file can simply refer their parent folder. Renaming a folder, or moving a folder to a new parent, does not need to update any files. You can take this a step further and have a three-level split: Tree, file-tree join table, and files. The tree describes the hierarchical structure of folders (which changes more rarely than files do), while the file-tree join table is essentially [folder_id, file_id]. When a file is moved, only the join table (which is much smaller than the files and super sortable and compressible) must be updated. I take the point that updating multiple discrete pieces of information puts more demand on the transactional layer, which has to ensure atomicity and consistency. But I'm surprised it wasn't even mentioned as an alternative that was evaluated and rejected. The article starts out with the premise that a flat key/value approach is the only choice on the table.
- alexhnn 4mo agoWorking with files is hard [1], and most of the complicity is from the fsync API. I am glad it can be eliminated from a kv storage engine. [1] https://news.ycombinator.com/item?id=42805425 https://news.ycombinator.com/item?id=42805425
- dboreham 4mo agoAlmost full-circle back to when Oracle took over the entire volume and implemented its own filesystem.
- dale_glass 4mo agoI wonder why this is not more common. LVM is easy to set up, and it's already common to allocate volumes for things like disk images for VMs, so why not databases?
- pizza234 4mo agoBecause the speed increase is - on modern, properly tuned filesystems - surprisingly small, due to how RDBMS's manage their pool; by working on large container files, they avoid most of the filesystem overhead.
- tptacek 4mo agoIf you preallocate and O_DIRECT, haven't you basically soaked up most of the benefit of skipping the filesystem?
- jandrewrogers 4mo agoSome Linux filesystems, notably ext4 and XFS, provide the necessary features to get 90% of the benefit simply by using O_DIRECT correctly. The last 10% is achieved by doing direct I/O to raw block devices, with the obvious caveat that this is not as easy to manage. Both of these are commonly done in database storage engines.
- hpcgroup 4mo ago[flagged]
- myself248 4mo agoTo step back a bit, the device still has a filesystem on it, and the structures described here are files within the filesystem? Just you're able to write directly into them, bypassing the filesystem layer, because you've constrained yourself to writes that don't require updating other parts of the filesystem structure?
- thomas_fa 4mo agoYes, that's right. We could go even further, to use the raw devices without relying on any filesystem. We then need to allocate/format raw disk spaces and we can not just open files as simple as right now. It would take some extra effort, but we would like to explore that in the future. It will also make the system initialization faster, since right now we need to write all zeros to make ext4/xfs to actually initialize extents as "allocated".
- nh2 4mo ago> fsync doesn’t just sync the file’s data, it syncs every piece of metadata the file depends on: ... directory entry Famously not, as the man page says. It is also said later in the article: > POSIX strictly requires a parent-directory fsync to make a newly created file’s existence durable. So I'm not sure why the dirent sync is claimed earlier.
- thomas_fa 4mo agoThanks for pointing it out the mistakes. We should make it clearer, when fsync an opened file descriptor, it would only sync its own metadata. To make it truly persistent, we need to issue another fsync for the directory fd, which would make it more expensive.
- zbentley 4mo agoI’m curious: what happens when a file and its metadata are fsync’d, but the dirent is not and the system loses power? If the file is brand new, does it show up as an orphan upon reboot, or is it just gone? Can you somehow access it by inode even if it’s not findable? Is this filesystem specific? Is there something else weird that can happen if the file is not new, not unlinked, but changes are made that would alter the directory entry in it in some way?
- matja 4mo agoEven with O_DIRECT and aligned blocks, I still don't understand how the storage engine can return a "successful commit" to the client without a sync at some point, because a sync (IIRC) is the only way to guarantee an ATA/NVMe FUA command is sent, and the device write cache/buffer is committed.
- klodolph 4mo ago:-/ it’s a statistical guarantee in the first place. A successful commit in a durable storage engine just needs to achieve some finite level of durability, like “10^-7 probability of loss per year”. The durability is a property of the whole system, and it is possible to achieve durability without fsync, you just may have a hard time explaining what the durability is, how you calculated it, and what the evidence or justifications are for the numbers you give. Even if you just look at hardware failure rates, you get unrecoverable I/O errors (data corruption) at about one in 10^15 bits, disk failures at a rate of about 1% per year, etc. People usually like to have better guarantees than those numbers give you with just a plain fsync anyway; so you are probably forced to do an analysis of the whole system if you want to provide good durability guarantees and be able to explain where the guarantees come from.
- asdfasgasdgasdg 4mo ago10^-7 (loss/record) * 10^8 (record/year) yields 10 data losses per year. If you're even a medium sized business you need a much better than 10^-7 probability of losses.
- Dylan16807 4mo agoThat's only true if your typical loss event loses one record. If you have a one in a million chance of an array failure taking out 10% of your production database, and otherwise have zero possibility of data loss, you also get 10^-7 losses per record. And I wouldn't assume they meant that number to be per record in the first place.
- 4mo ago
- 7e 4mo agoThis is really great work. Kudos to the team for such an elegant solution.
- thomas_fa 4mo agoThanks for the kind words! You check more of our work in https://github.com/fractalbits-labs/fractalbits https://github.com/fractalbits-labs/fractalbits.
- WindyBolt907 4mo ago[dead]
- QuietLedge375 4mo ago[dead]
- seastarer 4mo agoIt's more correct to use O_DSYNC in addition to O_DIRECT. This adds FUA to the disk write if the disk requires it for durability.
- thomas_fa 4mo agoYes, that has also been pointed out in other threads. Yes this could be very important settings, and even some of common Linux file systems actually don't do that every time and we need to disable the disk writecache during boot up to make sure the data truly persistent (as in my previous storage company).
- seebeen 4mo agoSo instead of saying "We removed fsync" you should say: "We redesigned the database write path to avoid paying the full fsync durability cost on every write"
- sethev 4mo agoThis seems sketchy. O_DIRECT skips the operating system's page cache, it does not guarantee that the SSD driver sent the data to the SSD or issued a flush to the drive itself. The data could still be in the driver's memory or the in non-durable memory in the drive itself when this engine says "ok, we're good". EDIT: sketchy from an answering "what exactly are the guarantees?" perspective
- jandrewrogers 4mo agoThe model here is that the storage device is directly reading and writing the userspace buffer via DMA. It is one of the reasons use of O_DIRECT creates additional constraints on buffer alignment and size. Some storage devices guarantee durability of non-persisted writes, which is explicitly part of their model. Consequently, the entire durable write path is the storage device completing a DMA read of their buffer. The underlying assumptions will not hold true for every environment. However, it will hold true for many and you can check most (all?) of them at runtime.
- sethev 4mo agoRight - I mean, what you're describing makes sense, but it doesn't sound like what they're describing. Their benchmarks are running on an EC2 instance and the post's author is here saying that they run on virtualized hardware. Plus they run on top of a file system. None of that screams "direct DMA from our buffers" to me. I'm not saying it's impossible, but typically people who want to lean on hardware guarantees for extra performance control more of the stack.
- mightyham 4mo agoUnless I am mistaken, it seems like there is a glaring flaw in this scheme, which is that without fsync you cannot guarantee the previous WAL blocks have been persisted before the current one, so a power loss event could leave a hole in the log and cause erroneous recovery. I believe that SSDs reorder writes internally so even having atomic batched O_DIRECT is not a strong enough guarantee for durability. I'll admit that I could be misunderstanding something about the system that alleviates this concern.
- seebeen 4mo agoI also asked what happens when a power loss happens.
- jandrewrogers 4mo agoMany storage devices guarantee that all successful DMA (e.g. O_DIRECT) writes are persisted even in the event of a power loss. This does not work on storage devices that do not offer this guarantee obviously. It also does not work if the filesystem does not support direct I/O or requires metadata updates. This is not a new trick. It has been used in many storage engine designs to effect durability without an fsync.
- mightyham 4mo agoThanks, that's interesting and I wasn't aware of that. Is there a consistent way to detmine if a device offers this garuntee at runtime on Linux?
- hedora 4mo agoAssuming O_DIRECT actually blocks until the SSD has acked (this isn't actually what O_DIRECT's contract says, but what they rely on), you have to wait until each page write acks whenever you need a persistence barrier. My guess is the preallocation + zeroing is what got them most of the win, and the O_DIRECT is actually hurting, not helping throughput. This has been the case 100% of the time I've benchmarked such things. If you're doing this sort of stuff for real under Linux, check out sync_file_range. It's the only non-broken and performant sync API for ext4 (note that it's broken by design for many other file systems, and the API is terribly difficult to use correctly). If you really care, it's probably just easier to use SPDK or something. Linux has historically been pretty hostile towards DBMS implementations.
- seebeen 4mo agoSo basically, you are writing data without guarantees it's actually written? "YOLO mode" but for data written to a device? Would you be so kind to explain what happens in a power-loss scenario?
- deleted 4mo ago[deleted]
- loeg 4mo agoThis design ACKs writes that aren't yet durably persisted (to the journal or data areas). That might be ok, but it might not. It's certainly unusual not to at least persist the journal update.
- zzsheng 4mo agonop. we will not ack any write which is not in data or journal. please check the put details in the blog.
- loeg 4mo agoYou initiate a write to the journal, but do not sync it before ACKing to the client.
- zzsheng 4mo agojournal file was pre-alloacated and we use direct-io for journal write so no need to call fsync.
- deleted 4mo ago[deleted]
- loeg 4mo agoAgain, it is not durably persisted before acking to the client. Like I said earlier, that might be fine for your durability model, but it is unusual.
- thomas_fa 4mo agoWe would wait for Bss data and journal DirectIO and the acking (sending response back to api_server) in the callback function. What you are implying is what s3 actually doing and you can get see from their paper[1] and we are stronger than that. [1]https://www.amazon.science/publications/using-lightweight-formal-methods-to-validate-a-key-value-storage-node-in-amazon-s3 https://www.amazon.science/publications/using-lightweight-fo....
- bradfa 4mo agoThere’s lies, damn lies, and lies that disks tell the operating system. Don’t believe any of them! If you need to know it’s been persisted to non-volatile storage then you need to own the full stack of every piece of software between the OS and the actual physical memory. Every managed flash drive is going to have layers and layers of complexity and caching and things you simply can’t easily control or really understand. Don’t trust it unless you know exactly how it works all the way down.
- thomas_fa 4mo agoWell said and there are some bitter lessons in the storage industry. In my last company we need to disable the disk write cache during each reboot, and we also heard a lot industry stories related to underneath firmware implementation from oxide computer podcasts [1]. Yes, to provide truly reliable service, we need to evaluate underneath hardware settings case-by-case. [1] https://onthemetal.transistor.fm/ https://onthemetal.transistor.fm/
- uroni 4mo agoIn my similar project (s3 compatible single-node storage) https://github.com/uroni/hs5 https://github.com/uroni/hs5 I do use proper fsync for data and metadata durability. But it can be turned of via switch. It is a pet peeve of mine that the defaults should always be to fsync. I do have a section on this in my README of the project. I also do have an optional WAL. Maybe I should add an additional mode that disables fsync only for the WAL. I don't think it would be a good idea. My WAL does use checksums and sequence numbers etc. to prevent committing wrong data.
- jnwatson 4mo agoIf you're bypassing the page cache, what invalidates the page cache so that the next read (from the filesystem) isn't stale?
- up2isomorphism 4mo agoThe repo seems to contains some api gateway, and none of actual storage engine is open sourced. I did it so you don’t have to waste your time to find out.
- yencabulator 4mo agoLooks violently non-open-source: https://github.com/fractalbits-labs/fractalbits/issues/8 https://github.com/fractalbits-labs/fractalbits/issues/8
- up2isomorphism 4mo agoS3 was never designed for performance. Trying to be compatible while going with very hardware dependent low level optimization seems to be a wrong direction to begin with.
- zzsheng 4mo agocheck s3 express one zone
- up2isomorphism 4mo agoStill slow as hell, if you think 10ms is fast that’s a different story.
- QuietLedge375 4mo ago[dead]
- ovaistariq 4mo agoThere is no way to reliably prove that bytes have made their way to the disk without issuing fsync. Thus, without it you cannot guarantee that writes ACKed to the client survive any failure afterwards
- CalmBirch127 4mo ago[dead]
- HollowRidge427 4mo ago[dead]
- yencabulator 4mo agoI would much rather talk NVMe from userspace than trust this to pass through kernel and filesystem with the correct guarantees.