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