# When will "Uncollected Garbage" be deleted?

**URL:** <https://forum.storj.io/t/when-will-uncollected-garbage-be-deleted/27327>\
**Category:** troubleshooting\
**Tags:** ttl, garbage-collector\
**Created:** [July 28, 2024, 8:32pm UTC](https://forum.storj.io/t/when-will-uncollected-garbage-be-deleted/27327 "2024-07-28T20:32:08Z")\
**Posts on this page:** 1\
**Showing post:** 256

<div class="post-metadata">

**Author:** ![thepaul](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/thepaul/32/65_2.png) [@thepaul](https://forum.storj.io/u/thepaul)\
**Post date:** [August 15, 2024, 4:49pm UTC](https://forum.storj.io/t/when-will-uncollected-garbage-be-deleted/27327/256 "2024-08-15T16:49:28Z")

</div>

> [@Toyoo](#):
>
> I like it. One nitpick to a comment:
> 
> ```auto
> // SetExpiration sets an expiration time for the given piece ID on the given satellite. If pieceSize
> // is non-zero, it may be used later to decrement the used space counters without needing to call
> // os.Stat on the piece.
> 
> ```

The OS does have to read the inode on `unlink`, but of course it unfortunately doesn’t return any of the info from the deleted inode to the `unlink` caller. We have to call `stat` separately. I’m not sure why a subsequent `unlink` doesn’t read the inode from cache at that point, but some profiling (on ext4+linux) suggests that it does not, in at least some cases. Maybe for something like a delete, a cached inode is not good enough? I haven’t gone into depth here.

> [@Toyoo](#):
>
> I would also be worried about the default size of the LRU cache, 1000 is close to a popular default of 1024 of max open files per process on many systems. Though with golang liking I/O they might have solved it in a different way 🤷

This hadn’t occurred to me. I was under the impression most people ran their nodes with a much higher RLIMIT\_NOFILE. Is 1024 even enough to run a fair-sized node in normal operation?

---

_[View the full topic](https://forum.storj.io/t/when-will-uncollected-garbage-be-deleted/27327)._