• [6.12.1] Unintentional partition wipe when assigning different disk to pool


    Jaybau
    • Minor

    When assigning a different disk to the same pool without re-setting the pool, Unraid will automatically wipe the assigned disk without warning and confirmation.  This leads to an unintentional wiped partition, data loss, and advanced partition recovery if lucky.

     

    This problem is too easy to do, and too disastrous.  It either shouldn't be this easy to do, or ideally impossible without explicit user consent to destroy data.

     

    Context:

    Lost drive after creating pool (v6.12)

    Quote

     

    ...assigned that disk to a pool, started array, stopped array, then assigned a different disk to the same pool without re-setting the pool, this will make Unraid wipe the previously assigned disk.

     

    since v6.12 Unraid wipes the full device, destroying the partition layout

     

    Version 6.12.1 2023-06-20

     

    Thank you.

    tower-diagnostics-20230624-0856.zip




    User Feedback

    Recommended Comments

    I think adding a warning requiring typing YES to acknowledge before the wipe command is executed would be sufficient.

     

    Maybe it would be a good idea to add a new section to the "New Config" area to manage the resetting of pools. Limit the current new config reset to parity array only, and add individual line items for each currently defined pool.

    Link to comment

    I again ran into a similar scenario here:  https://forums.unraid.net/topic/142155-replacing-single-cache-device-on-unraid-v6123/

     

    There is no reason for Unraid to touch the partition/filesystem in these scenarios.

     

    If Unraid didn't touch the filesystem in these scenarios, there would be no problem for me.  The drive simply could have been placed in the Unassigned Devices, with its partition entact, nothing touched on the drive.  

     

    Here's my proposed simple solution:

     

    1)  Unraid should NOT touch the drive's filesystem/metadata/partition information when a device is added/removed from a pool. 

     

    Quote

    Maybe it would be a good idea to add a new section to the "New Config" area to manage the resetting of pools. Limit the current new config reset to parity array only, and add individual line items for each currently defined pool.

     

    I would think Unraid could be smart enough to know that if I'm moving devices between pools, that would automatically mean a "new config" (or change of an existing config).  I don't want to create a new config, lose the config, and have to redo the config for what hasn't changed.  Once I make the changes on "Main", and "Start" (or save if it existed), Unraid should safely handle the changes.

     

    I was going to eventually ask for something that I think is related to above...  I think pools that don't use the array need to be separated.  There's no reason to stop the array to manage pools that are not using the array, or have dependencies on other pools.  Each pool should be independent.  I should be able to stop any pool, manage it, and restart the pool, without affecting the other pools, cache, array.

     

    Thank you.

     

     

     

    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
    Add a comment...

    ×   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.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.