Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Files deleted via the UI are removed from MFS but not deleted from repo #1061

Open
JohnVersus opened this issue Jun 21, 2019 · 11 comments
Open
Labels
P3 Low: Not priority right now status/blocked Unable to be worked further until needs are met

Comments

@JohnVersus
Copy link

How do I transfer storage from C: to any other disk. Apparently even after deleting the hosted files from IPFS Desktop, the storage in C drive doesn't get removed.

So is there a way to change where I host the files?
image
image
image

@olizilla
Copy link
Member

Right now, deleting from the UI makes the blocks available for garbage collection, but doesn't trigger garbage collection. You can do so manually by running ipfs repo gc from the commmand line which will remove all the blocks that comprise the files you deleted from the UI.

This is less than ideal. We should consider triggering a GC when the user deletes a file.

@olizilla olizilla changed the title Storage transfer Files deleted via the UI are removed from MFS but not deleted from repo Jul 17, 2019
@olizilla olizilla added help wanted Seeking public contribution on this issue P1 High: Likely tackled by core team if no one steps up labels Jul 17, 2019
@olizilla
Copy link
Member

@lidel can i get your opinion here? I think triggering a GC would be a simple step to making this less suprising.

A fancier solution would be to introduce a notion of a trash folder, and have deleting things just mean moving them to that folder, and then provide an "empty trash" button that deletes everything in the trash folder and then runs a GC... but I'm not convinced we need that today.

@hacdias
Copy link
Member

hacdias commented Jul 17, 2019

@olizilla I don't like the idea of running the GC every time the user deletes a file. It might get slow if the repository is big I think.

But I think we could have a way in the interface to run the GC.

@olizilla
Copy link
Member

Ok, we could grab the list of CIDs for the file and remove them explicitly. Feels like a delete should remove the file altogether. It's not possible for us to restore the file with the current code, so it's weird for the user to delete a thing but have it still take up space.

@ericronne
Copy link

🗑 🤗

@olizilla
Copy link
Member

@ericronne is that a vote for a trash folder ?

@ericronne
Copy link

Would love to test that notion with users. Fully embracing the "garbage" metaphor that we've already established.

@lidel
Copy link
Member

lidel commented Jul 19, 2019

What if:

  • We add a button on Settings page to enable user to manually "Free up space by removing unused blocks from local cache"
    (unused sounds better than "unpinned" and works better with MFS vs cache abstraction)
  • Add option to Delete dialog window that lets user to "Immediately remove unused blocks from local cache", should be less prominent, eg:

    2019-07-19--15-00-33

    • If we don't do fancy lookup&drop of blocks related to the file and always trigger global GC, perhaps this could be simplified to something like "Delete and compact cache"

@hsn10
Copy link

hsn10 commented Mar 31, 2021

dont auto trigger gc not only its quite long and io heavy slowing machine, it will delete too much data.

I like current behavior. If we are bellow GC size limit we are okay on diskspace and no point in trying to do stuff to save space.

@lidel
Copy link
Member

lidel commented Mar 31, 2021

Ack, We decided to not touch GC until go-ipfs provides improved GC with a command to run GC check over a specific DAG behind a CID (instead of full repo): ipfs repo gc --cid=<cid>

Ref. protocol/web3-dev-team#8

@lidel lidel added P3 Low: Not priority right now status/blocked Unable to be worked further until needs are met and removed P1 High: Likely tackled by core team if no one steps up help wanted Seeking public contribution on this issue labels Mar 31, 2021
@hsn10
Copy link

hsn10 commented Mar 31, 2021

This will not be fast too. you need first to build recrusive list of all cids from pin roots and then start travrl your cid to be deleted and delete only parts if referenced blocks frm your cid are not referenced from pins too.

building these lists takes a long time unless you have small repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 Low: Not priority right now status/blocked Unable to be worked further until needs are met
Projects
No open projects
Status: Needs Grooming
Development

No branches or pull requests

6 participants