sdfyjert Posted October 25, 2020 Share Posted October 25, 2020 Here's the situation, I deleted some files (movies) using Plex. The titles got removed from Plex and the files no longer exist in the respective share. After noticing that the disk space is not freed I checked the actual hard disk (i.e. /mnt/disk1/movies) and the files are still there. Clues The array is entirely on xfs (latest version of unraid). At the same time the parity was being built (parity first time - just added the parity drive today) There was some "intense" activity throught the array and caches (fyi: this share does not use cache, cache = NO) Is this a bug or something expected? Will the files be automatically removed later (ie. after the parity build is finished) or I have to manually go and remove them? Quote Link to comment
itimpi Posted October 26, 2020 Share Posted October 26, 2020 The file should not exist if it has really been deleted as that happens in real time. how did you check that the file does not exist in the share? It should show up if you view it via the GUI if it is on the disk as the share is simply an alternative view of the disk contents. I think you are going to have to manually delete the file, but it seems a good idea to try and work out why this happened in the first place. The fact you were building parity at the same time should be irrelevant (except for the performance hit it introduces). Parity is not aware of files (or file systems) as it works purely at the disk sector level. No idea if it will help but posting your system diagnostics zip file (obtained via Tools->Diagnostics) might be worthwhile to see if anyone can spot something. Quote Link to comment
sdfyjert Posted October 26, 2020 Author Share Posted October 26, 2020 Update coming next morning, the files that were removed from the share but where still on the disk reappeared on the share 🤔 I removed them again from the share and this time they're gone for good. Quote how did you check that the file does not exist in the share? ssh, `ls /mnt/user/movies > /mnt/user/tmp/movies_share.txt` and `ls /mnt/disk1/movies > /mnt/user/tmp/movies_disk1.txt` and run a diff on the files (though I'm dead certain there's a faster way with pipes) Quote Parity is not aware of files (or file systems) as it works purely at the disk sector level. I understand how 1+1+1+1 = 1 works (🤣) I thought maybe during parity build it locks some sectors? If not the case and considering it's fs driver level perhaps something relating to concurrency. If it happens again Quote No idea if it will help but posting your system diagnostics zip file I highly doubt it will be of any use but here it is for what it's worth inas-diagnostics-20201026-1003.zip Quote Link to comment
itimpi Posted October 26, 2020 Share Posted October 26, 2020 I must admit I could not spot anything in the diagnostics to explain what happened 4 hours ago, sdfyjert said: understand how 1+1+1+1 = 1 works (🤣) Except that as far as parity is concerned the answer is 0 Quote Link to comment
Recommended Posts
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.