It seems I have created some confusion. This version of UCS (let's call it V2) is ahead of the one in DSE (V1), with the main difference that it no longer uses a fixed number of shards. Because of this, V2 acts similar to LCS in the required extra space, because the sstables it constructs aim to be close to a target size. V1 UCS had some special features to deal with the large sstables it created in the top levels of each shard, which are not as important for V2: when the target size is small enough, there should be no need for limiting compactions to the available free space, or for making sure that large top-level compactions cannot cause sstables to accumulate on L0.
Because of this, such features of the V1 UCS have been omitted in order to keep the initial commit small enough to fit the C* 5 timeline (they rely on some sizable refactorings of the compaction interfaces which should come at a later date). Regards, Branimir On Sat, Mar 18, 2023 at 1:05 AM Jeff Jirsa <jji...@gmail.com> wrote: > I’m without laptop this week but looks like CompactionTask# > reduceScopeForLimitedSpace > > So maybe it just comes for free with UCS > > > On Mar 17, 2023, at 6:21 PM, Jeremy Hanna <jeremy.hanna1...@gmail.com> > wrote: > > You're right that it doesn't handle it in the sense that it doesn't > resolve it the problem, but it also doesn't do what STCS does. From what > I've seen, STCS blindly tries to compact and then the disk will fill up > triggering the disk failure policy. With UCS it's much less likely and if > it does happen, my understanding is that it will skip the compaction. I > didn't realize that LCS would try to reduce the scope of the compaction. I > can't find in the branch where it handles that. > > Branimir, can you point to where it handles the scenario? > > Thanks, > > Jeremy > > On Mar 17, 2023, at 4:52 PM, Jeff Jirsa <jji...@gmail.com> wrote: > > > > > On Mar 17, 2023, at 1:46 PM, Jeremy Hanna <jeremy.hanna1...@gmail.com> > wrote: > > > > > One much more graceful element of UCS is that instead of what was > previously done with compaction strategies where the server just shuts down > when running out of space - forcing system administrators to be paranoid > about headroom. Instead UCS has a target overhead (default 20%). First > since the ranges are sharded, it makes it less likely that there will be > large sstables that need to get compacted to require as much headroom, but > if it detects that there is a compaction that will violate the target > overhead, it will log that and skip the compaction - a much more graceful > way of handling it. > > > Skipping doesn’t really handle it though? > > > If you have a newly flushed sstable full of tombstones and it naturally > somehow triggers you to exceed that target overhead you never free that > space? Usually LCS would try to reduce the scope of the compaction, and I > assume UCS will too? > > > > >
