Jump to content
LAST CALL on the Unraid Summer Sale! 😎 ⌛ ×

Editing and deleting files should be done by mover


Recommended Posts

Whenever a file is deleted or edited that is on a share with primary storage Cache and secondary storage Array, the entire Array needs to start up in order to do this. This is very slow (start-up time) and regularly makes it necessary for all drives to spin-up, which is not energy efficient.

 

What I think should happen:

 

When a file from Array is edited, create the edited file on cache. Whenever I access that file with /user/SHARENAME/.../file the file from the cache gets displayed. When the mover is activated, the file on the array gets replaced by the file from Cache.

 

When a file from Array is being deleted, create an empty file in /cache/[DELETED]/SHARENAME/.../[FILENAME]. When listing files in /user/SHARENAME/... all files that are in /cache/[DELETED]/SHARENAME/ get filtered out and are not displayed. Once the mover starts, all files in [DELETED] get deleted from the array.

 

Advantages:

- Lower energy cost, especially for systems with a lot of drives

- Fast reaction time whenever drives would need to spin up

- Recently edited files would be in Cache

- Possibility to recover wrongfully deleted/edited files (until mover-action)

- Parity drives only need to spin up for mover

Disadvantages:

- Any edits are not protected by array similar to new files (until mover-action, but would only lose edits not the entire file if cache stops working)

- Deleted files can be recovered (can be viewed as disadvantage for privacy reasons)

- If someone accesses files through /disk1/[SHARENAME]/..../file he would see outdated or deleted files

 

Since there are some minor disadvantages, this should be an optional feature that can be activated for any share with secondary storage. 

 

Implementation is obviously up for discussion, but I think it would make Unraid a lot better if Cache would be utilized more and it isn't needed to spin up all drives whenever a file is deleted or edited.

Link to comment

There is a fundamental assumption built into Unraid that a file only exists in one location at a time, so it can either be on a pool or on the array, not both.    Your idea would mean that this assumption would no longer be true which could have all sorts of consequences.

Link to comment

I understand that this feature isn't something that every user would want, which is why it should be optional and disabled by default.

 

It would also need a lot of testing, but I hope you understand the quite massive advantage that you don't have to spin up 11 hard drives when editing a 10kb txt file.

Link to comment
  • 2 weeks later...

While it would require fundemental changes, and probably won't happen for that reason, it's quite a nice idea.

 

It doesn't really make the data any more vulernable - outside of edits - if the cache drive were to die before the mover triggered, but it has a bunch of performance and energy advantages.

 

+1, fwiw

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...