thank god for a sane person. thank you very much. I appreciate the help sincerely. I do agree that they should post themselves, but as I do what I do as an indexer mod, I kind of do shoulder some amount of burden to them and I'm happy to do it. I like helping people. I sit in out chat and help people day in and out. I have never, ever, treated someone like this, even a total n00b. Again, I appreciate the ACTUAL help and guidance. Thank you very much

 

Give a man a fish and he'll eat for a day, teach a man to fish and he'll eat for a lifetime.... 

 

Although, granted some people like a spoon and have no interest in fishing... lol 

 

Although I take umbrage with you referring to me as sane.... 

Mike, I'm inclined to think this is either a problem with sabnzbd or a cache drive issue.

 

This issue looks similar to yours

 

Got a spare drive you could test as a different cache disk?

Also worth checking if any of your plugins need updating as V6.2 moved to Slackware 14.2/Current from Slackware 14.1.

It seems to me that we need to know more about what the state of the files are on the BTRFS volume before unRAID tries to move them to the array.  Even a simple 'ls -l' of such a file may help to give some idea.

 

There was a mention of symlinks.    If there are actually any of these and they refer to the cache device then I can easily see the files appearing to disappear when you try and move the symlink if the symlink is no longer valid in its new location (because symlinks are not allowed to cross device boundaries).  If the problem could be narrowed down to symlink handling then I suspect that an appropriate fix can be found.  It might also be worth doing a 'ls -l' command at the target location.  I think that broken symlinks do not show up at the share level but they may show up at the raw Linux level.

Updated all plugins and dockers, lost and deleted powerdown from /boot as recommended. I'm trying to use unbalance to move things from my old resiserfs disks and replace them with xfs disks now. I will report back. Thanks for the actual help guys

Interestingly I found reference to the errors you are seeing within the Unbalance thread.

 

 

Sorry I don't click lmgtfy links, but I found some references although I don't understand why that would have anything to do with this.

Sorry I don't click lmgtfy links, but I found some references although I don't understand why that would have anything to do with this.

 

Well the error code was the same as you're seeing in your setup, I don't understand what the problem was with the link, but I thought it may have helped.  I used it to cut down on all the cruft I got when I tried to to copy pasta a google link that was about 3 lines long, seemed neater.

 

Guess I'll leave you to it if my help isn't required...

No I appreciate the help, we've just always used lmgtfy links as kind of "here dummy" type of things on NZBGeek I'll take any actual help I can get at this point.  I did find the references you mentioned. I just don't understand how they pertain to this issue. Although I do also find it interesting there is this issue in unbalance as well. I think there is some type of issue in 6.2 going from BTRFS to ReiserFS. I've taken a few different types of files, some created by SAB and others not created by SAB. The issue persists whether they are created with SAB or not. Anything that starts out on the cache drive when copied to an XFS drive is fine. So even changing where Sonarr copies SABs downloaded and unpacked files to /mnt/disk# (some XFS only disk) everything is smooth sailing. When I use /mnt/disk# (ReiserFS) the moment the file copy finishes, it vanishes.

 

I've taken to not using unbalance as it seems to hang for the same reason, and I'm just using midnight commander to move all of my files to XFS disks that have room, then reformatting them. I can't seem to wrap my head around the problem, so this is the only solution I can see that works. So I think the issue is definitely going from BTRFS to ResierFS, and this issue has only manifested in 6.2.

No I appreciate the help, we've just always used lmgtfy links as kind of "here dummy" type of things on NZBGeek I'll take any actual help I can get at this point.  I did find the references you mentioned. I just don't understand how they pertain to this issue. Although I do also find it interesting there is this issue in unbalance as well. I think there is some type of issue in 6.2 going from BTRFS to ReiserFS. I've taken a few different types of files, some created by SAB and others not created by SAB. The issue persists whether they are created with SAB or not. Anything that starts out on the cache drive when copied to an XFS drive is fine. So even changing where Sonarr copies SABs downloaded and unpacked files to /mnt/disk# (some XFS only disk) everything is smooth sailing. When I use /mnt/disk# (ReiserFS) the moment the file copy finishes, it vanishes.

 

I've taken to not using unbalance as it seems to hang for the same reason, and I'm just using midnight commander to move all of my files to XFS disks that have room, then reformatting them. I can't seem to wrap my head around the problem, so this is the only solution I can see that works. So I think the issue is definitely going from BTRFS to ResierFS, and this issue has only manifested in 6.2.

 

Oh, ok, well now you've done some tests it sounds like some sort of ReiserFS issue as it's not even working if you directly write to it. 

It is very weird though for sure. You would think if there was some issue it wouldn't even allow the file copy. But it definitely does. So for instance, Sonarr gathers metadata for me. When it moves things to a ReiserFS disk, it even allows all of the files to appear on the ReiserFS disk. So moviename.mkv moviename.nfo fanart.tbn etc. But the moment the mover finishes, I keep ls-ing the directory in /mnt/user0, watching the mover do it's thing and the moment it seems like the command completes (all the files are there), another ls, and poof, they're gone.

If you create a file at the console on the drive in question, (touch /mnt/diskX/test.txt) does it persist?

Yes, as does just a straight cp or mv command. I believe this problem is possibly specific to rsync-ing between BTRFS and ResierFS, as both trying to use the UnBalance plugin and using rsync from the CLI both throw the same types of failures. I am assuming this is also how the mover works also, but I don't know enough about it to be sure. I would think it does as it has the extra benefit of checking file integrity. So I think that CHBMB is exactly correct that the user in the unBalance thread and my problems are identical.

some points:

• the mover is using a custom(?) binary /usr/local/sbin/move to do the actual operation
  
• the problem seems to be the rsync operation [as seen in the syslog] is failing to transfer the files xattrs (thus aborting the transfer altogether) but it seems that the delete operation on the cache files still proceed.
  

Are the source files symbolic links or hard links? an ls -l output would answer the problem.

maybe LT can shed light whether this binary is as atomic as needed (or is just a script made into an executable...)

The source files are actual files on the cache drive. The symlinks are created in /mnt/user like usual but when the mover runs, I watch the actual files hit /mnt/user0 using midnite commander (it shows symlinks as another color), and as soon as the entire move is complete, all of the files in /mnt/user0/media and /mnt/cache/media are gone.

wait run that by us again.

 

ie

the source file: /mnt/cache/media/file.mkv

I don't see a symlink. (not in /mnt/user)

 

Again I think the move binary might be at fault. the failed/incomplete rsync seems to be triggerring the removal afterwards.

Just as an example: Sonarr downloads an episode, and places it in /mnt/cache/media/tv/showname/episode.mkv

and a symlink is placed in /mnt/user/media/tv/showname/showname.mkv

as I thought was expected behavior. Then the mover runs.

I watch through midnight commander, the mover moving the actual file from /mnt/cache/media/tv/showname/episode.mkv

to : /mnt/user0/media/tv/showname/episode.mkv

along with any accompanying metadata files in the same fashion. When the mover completes, all files and symlinks vanish from both locations.

 

Just throwing this out there, I thought ResierFS doesn't fully support xattrs, hence the requirement of using XFS for the file integrity tool.

Just a note: there are no actual symlinks involved. (And I can get anal-retentive about wrong usage of certain terms.)

 

You keep calling the files in /mnt/user as symlinks - which is confusing me.

They are not symlinks. they are actual files with another directory listing using the shfs. Its like a bind mount where a directory is made available elsewhere but still referencing the same files. I'm still thinking the move binary is at fault as its the one invoking rysnc and doing the deletes after.

 

I think we need LT to give us an answer for this.

 

Just throwing this out there, I thought ResierFS doesn't fully support xattrs, hence the requirement of using XFS for the file integrity tool.

yes, well regardless, the mover should not fail like this (If i'm getting it right).

Yes you are correct, I am using the wrong terminology, but that is what is happening.

 

Just throwing this out there, I thought ResierFS doesn't fully support xattrs, hence the requirement of using XFS for the file integrity tool.

yes, well regardless, the mover should not fail like this (If i'm getting it right).

 

I don't think Mover (Read Rsync) is failing. I do think that ResierFS is failing.

I agree, and I'm glad the symlink thing is cleared up as that was confusing me too...

 

People kept mentioning symlinks and I couldn't see why?

 

Sent from my LG-H815 using Tapatalk

 

So I have transferred the entire contents of drive1, one of my reiserfs drives, to another drive. I have tried stopping the array, removing the partition on disk1, formatting to xfs, and no matter what I do, it keeps appearing in the MAIN tab as reiserfs. Even when I stop the array, unassign the disk, it shows in unassigned devices as xfs, but when I try to add it back to the array, it shows as resierfs. So I have one empty disk, disk1. What is the correct method to format it to xfs and add it back into the array as a new, blank disk with nothing on it?

My guess is some sort of new config without that drive, parity sync, preclear drive, re-add it the array as a new drive, but that seems a bit clunky and I'm sure there's got to be a better way of doing things.

 

Sent from my LG-H815 using Tapatalk

 

 

I agree that is going to be a real task considering I need to do this with 5 reiserfs drives. Why even though it's been formatted, the partition deleted, and re-added does unRAID still insist on it being a reiserfs drive?