Why is data writing to drives it's excluded from?


Recommended Posts

I have two shares Stuff and Scratch

I have the Stuff share assigned to only drives 1-7 and have excluded drives 8-9.

Scratch is assigned to drives 8-9 and excluded 1-7.

 

I'm finding items that have been copied into a directory in the Stuff share on drives 8-9.

Does this have to do with the split directory setting?

Link to comment

How should I be setting the split then? At the moment it's set to split as required.

 

Do splits override includes?

 

If I set to only include the disks in the share it shouldn't use any drives that are in the exclusion, right?

 

 

Edited by thegurujim
typed "inclusion" instead of "exclusion"
Link to comment

I've changed it to just setting the drives for inclusion now.  I'm moving the data from the other disks to the proper disks and see how that goes.

 

Although I did set both, it should still follow the "rule" I set. 

 

Squid's reply that makes me wonder why a split would not follow the include/exclude rule and how I'm supposed to set the split so it won't write to drives I don't want it to write to.

Link to comment

How does one move files from one share to another when the shares in question aren't supposed to exist on the selected disks?

 

Moving the files between shares using the Krusader or Dolphin docker apps results in the files just creating the share in the disk it's already on.

 

Moving it using Windows, actually moves the files from disk to disk.

 

Nothing I choose in the split settings seems to make it move the file from disk to disk while using Krusader/Dolphin.

Link to comment
4 minutes ago, thegurujim said:

How does one move files from one share to another when the shares in question aren't supposed to exist on the selected disks?

 

Moving the files between shares using the Krusader or Dolphin docker apps results in the files just creating the share in the disk it's already on.

 

Moving it using Windows, actually moves the files from disk to disk.

 

Nothing I choose in the split settings seems to make it move the file from disk to disk while using Krusader/Dolphin.

You cannot do it the way you want.    This is a quirk of the way Linux (and many other OS)  tries to optimise move operations.    If it thinks that both the source and target are on the same mount point then it first tries a rename, and only if that fails does it do a copy/delete operation.  

Link to comment

You should never mix disks and user shares when moving or copying files. In Krusader, etc., you can move the files from disk to disk. The user shares are just the top level folders of all disks, and if you want to move things manually from one disk to another, just use one disk as source and another disk as destination.

Link to comment

Its because you're only passing through a single mount point (probably /mnt) to krusader.  As Itimpi states, because the shares are all on the same mount point, Krusader (rightfully so) does a simple rename operation)  Every OS created will do the exact same thing.

 

Your easiest thing to do here is to simply move it from one share to the other via Windows over the network.  Each share is a different mount point over a network.

Link to comment

Let me clarify - Split level does not override the include/exclude settings to place a share directory. A share will not be created on a disk that doesn't have it because of the split level settings. So, this already means your case is not a split level issue since you found the share was getting created on excluded disks. Since that was what you asked, that is what I answered.

 

But to go further, the only case where the split level overrides the excluded disks occurs if the directory structure down to the level NOT allowed to split already exists on the excluded disk. In other words, when the directory exists on the excluded disk and the split level is set so it has to write to that directory. The share can exist on the disk and yet the disk can still be excluded as long as the split level setting doesn't force the data to go to a directory on that excluded disk. Your split level settings mean this case can never happen.

 

So, split level will never create the top level share directory on an excluded disk and your split level setting would never write to an excluded disk even if it contains the share already. Hence, it is not your split level overriding the include/exclude settings.

 

You're running into a Linux "problem" where the move is simply re-naming the files hence they don't move disks. Years ago, that even used to happen when copying share to share from Windows too, but it works as expected from Windows now.

Edited by lionelhutz
Link to comment
1 hour ago, Squid said:

Every OS created will do the exact same thing.

That depends - you can ask the OS what the true mounted device is for source and destination file.

 

Such a test will work for files on /mnt/diskX/xx

 

But /mnt/user/ is a single mount and I don't think FUSE has support to allow it to report the actual underlying mount point - I think the only possible response will be /mnt/user/

 

Link to comment

I would try this. Go to the bottom of the container setup and click the add a new path. Name it Stuff. Put in /Stuff for the container side. Pick /mnt/user/Stuff for the host side. Repeat for Scratch. Delete the /mnt host path so you don't use it by mistake. In the container when you move from /Scratch to /Stuff it should obey the share settings correctly.

 

Link to comment

Shares are nothing more than groupings of files that are on the same named root folder of the array disks and cache. Include / exclude setting are ignored. So if you have a "Movies" folder on disk1 and a "Movies" folder on disk2, and then configure the "Movies" share to exclude disk2, you will still see the files on both disk1 and disk2 in the share.

 

When a file is written to the share, if that file already exists, it will be overwritten. Even if the file exists on a disk that is excluded (or not included).

 

When a file is written to the share, and based on your split level rules, its directory is non-splittable and that directory already exists at or beyond the split level, the file will be added to that subdirectory on the disk. Even if that disk is excluded (or not included), goes against the allocation method, or even if there is not enough room for the file.

 

When a file is written to a share and it does not already exist and the split level doesn't force it to a specific disk, the include/exclude settings (as well as the the allocation method) come into play. unRAID will put that file on an included / not excluded disk.

 

There is a global user share setting that can totally exclude a disk from user share functions. If a disk is excluded in this way, it will not  appear in any user shares and never be written to as part of a user share.

 

(#ssdindex - user share rules)

  • Upvote 2
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.