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