unRAID 6.0b6 share moving/leveling best practices?

[METDeath]

Since there's not a subsection for 6.x yet, and I'm not running 5.x I'm not sure where exactly to put this thread...

 

Here goes, so in the process of converting my existing file server over to unRAID I have had to use some less than ideal methods for how I want my data sorted on my file server. Such things as using smaller drives than I want to use, or only using one drive until more precleared for that particular share. (only five drives left to copy from and then convert... yay)

 

So my questions are as follows:

 

What is the best way to move a share from one HDD to another? (call it 3 TB of data)

MC? cp command in a screen?

 

Is there a way to have the share adjust itself to high water instead of most free within the GUI or will I have to use MC/cp and do it myself?

 

If more details are needed, ask, I'm pretty quick about replying on the weekends.

 

[JonathanM]

MC in a screen session is the way I move data from drive to drive. Just navigate to the /mnt/disk? source on one side and /mnt/disk? destination on the other and use the ren/move function on the folder you want to move.

 

Changing allocation (high water, split level, includes / excludes) only effects new writes, unraid never moves existing data around by itself on the data drives of the parity protected array. The only built in automatic move function is from the unprotected cache drive to a cache enabled user share.

 

Due to a bad bug that hasn't been fully fleshed out yet, you should never move data from a location in /mnt/user to a location in /mnt/disk? or vice versa. Only move from /mnt/disk? to another /mnt/disk? location, or from one /mnt/user/? to another /mnt/user/? location. Don't mix and match.

[METDeath]

MC in a screen session is the way I move data from drive to drive. Just navigate to the /mnt/disk? source on one side and /mnt/disk? destination on the other and use the ren/move function on the folder you want to move.

 

Changing allocation (high water, split level, includes / excludes) only effects new writes, unraid never moves existing data around by itself on the data drives of the parity protected array. The only built in automatic move function is from the unprotected cache drive to a cache enabled user share.

 

Due to a bad bug that hasn't been fully fleshed out yet, you should never move data from a location in /mnt/user to a location in /mnt/disk? or vice versa. Only move from /mnt/disk? to another /mnt/disk? location, or from one /mnt/user/? to another /mnt/user/? location. Don't mix and match.

 

That's exactly how I did it /mnt/drive? to /mnt/drive?. When I copy stuff from a NTFS drive to a share, then I do it to /mnt/user/[share name] because I did a test copy to /mnt/disk?/[share name] and it didn't show up in the share... odd, huh?

[JonathanM]

When I copy stuff from a NTFS drive to a share, then I do it to /mnt/user/[share name] because I did a test copy to /mnt/disk?/[share name] and it didn't show up in the share... odd, huh?

Very odd. The user share system is just a merging of all the identical folders in the root of each disk. The only time I've seen behaviour like you are describing is when I accidentally had the root folder on one drive in a different case, and it would only show one at a time, not combined. I had a folder "movies" on one drive, and "Movies" on another, and the share didn't merge them, because the case was different, so the content of one of the folders wasn't in the user share. Windows isn't case sensitive by default for file names and paths, but linux is, so you can get some weird behaviour when you are mixing things.

[METDeath]

Yeah... I have noticed the case sensitivity, the case in my example was identical, I made it through a terminal. I haven't used Linux for a personal machine yet, simply because I prefer the availability of games on Win 7.

 

Rereading your post, and then mine I realized I use the wrong nomenclature and used /drive instead of /disk in a few spots. Well, I'll get it down eventually. (Insert nonchalant smirk here.)