# It seems that the new feature “save-state-resume GC filewalker” isn’t functioning as expected

**URL:** <https://forum.storj.io/t/it-seems-that-the-new-feature-save-state-resume-gc-filewalker-isn-t-functioning-as-expected/25874>\
**Category:** troubleshooting\
**Tags:** filewalker\
**Created:** [April 16, 2024, 5:47pm UTC](https://forum.storj.io/t/it-seems-that-the-new-feature-save-state-resume-gc-filewalker-isn-t-functioning-as-expected/25874 "2024-04-16T17:47:00Z")\
**Posts on this page:** 1\
**Showing post:** 51

<div class="post-metadata">

**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\
**Post date:** [June 12, 2024, 6:09am UTC](https://forum.storj.io/t/it-seems-that-the-new-feature-save-state-resume-gc-filewalker-isn-t-functioning-as-expected/25874/51 "2024-06-12T06:09:39Z")

</div>

> [@jammerdan](#):
>
> Maybe this information could be even moved to a different disk or even ramdisk then, freeing the data disk from inode reads for that purpose altogether.

This is already possible for zfs for example, exactly what you suggest. It wouldn’t be a ramdisk directly, but RAM (+SSD?) used to cache this metadata.  
It’s partially possible for ext4 too:

> [@Metadata cache ext4 (RAM maxed)](https://forum.storj.io/t/metadata-cache-ext4-ram-maxed/26216/5):
>
> I don’t think you can directly control what content is cached in RAM in ext4 as you can do in ZFS. Indirectly you can tune the vfs\_cache\_pressure parameter. As mentioned earlier someone used LVM to achieve storing metadata on SSD: [Ext4 speedup by storing metadata and data on separate devices](https://linux-ext4.vger.kernel.narkive.com/66JGZzf0/ext4-speedup-by-storing-metadata-and-data-on-separate-devices)

---

_[View the full topic](https://forum.storj.io/t/it-seems-that-the-new-feature-save-state-resume-gc-filewalker-isn-t-functioning-as-expected/25874)._