• [6.9.2] User0 is ignoring included disks


    -Daedalus
    • Solved

    Hi all,

     

    I have a backup share, restricted to disk2 in my array (this is to prevent hourly backups of smaller things getting scattered throughout other disks, preventing spin down).

    I've set the backup share to include only disk2, and all other shares to exclude this disk.

     

    With a weekly VM backup user script, I am copying from /mnt/user/domains (cache only) to /mnt/user0/backup/vm

    When this script runs, data is copied to /mnt/disk1/backup/vm

     

    This behaviour is also present outside of this script; it seems like anything copied from a disk or user share, to a user0 share with specifics disks, will ignore the disk specified.

     

    Diags attached, let me know if anything else would be of use.

    server-diagnostics-20211212-1341.zip




    User Feedback

    Recommended Comments

    Is the backup share a "new" share (ie: did you make it very recently?)  Try stopping and starting the array to see if that makes a difference...

    Link to comment

    Are you sure that share didn't already have files on disk1? When replacing files, they go to the disk already containing the file to be replaced.

    Link to comment

    Yup. I double-checked this. At first I thought that was what's causing the issue, because originally disks 1 and 2 were designated for backup, but I recently upgraded some disks, so I only need disk2 now. I removed the backup folder on 1, and the next time my VM backup script ran it just created a dir on disk1.

     

    I'm wondering if this has something to do with pools as well, because something similar - but not the same - happened when I was moving some other files around.

     

    I have an 'nvme' pool, and an 'ssd' pool.

    I was moving files on an nvme-only share to the backup share.

    The backup share uses the 'ssd' pool as its cache.

    When moving from /mnt/nvme to /mnt/user/backup, a 'backup' directory was created on 'nvme', rather than being moved to the existing 'backup' directory on 'ssd'

     

    I'm guessing this has something to do with pool/cache logic. If I remember right, it's setup in such a way that a given share can only have one cache associated with it, and there isn't really any logic for moving stuff between cache pools.

    It is something like, if the share is cache enabled, and the files are on *any* cache drive, then that must be the cache assigned to that pool, so I'd better create the dir if it doesn't exist.

     

     

    I'm not sure if these two things are connected in any way, but I figured I'd mention it.

     

    Link to comment
    5 minutes ago, -Daedalus said:

    I'm guessing this has something to do with pool/cache logic. If I remember right, it's setup in such a way that a given share can only have one cache associated with it, and there isn't really any logic for moving stuff between cache pools.

    This is really only about how mover works.

     

    Link to comment
    3 hours ago, Squid said:

    Is the backup share a "new" share (ie: did you make it very recently?)  Try stopping and starting the array to see if that makes a difference...

     

    It was one of the first I created years ago, but the disk changes are recent. I'm pretty sure the array has been restarted since doing that, but I'll give it a go once there's not much happening.

    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.