Pourko

You can move this thead to the proper place then.

A somewhat related thought... It puzzles me that the md driver was made to work on partitions. Feels like it could have been more cleanly implemented if it worked with the raw disks instead, agnostic about partitions.

Over the years I have always known that, should such an occasion arise, I can always mount (ro) any of my data disks in a different linux computer. Yesterday I actually needed to do just that, and to my surprise, I was not able to do it: # mount -t xfs -o ro /dev/sdc1 /tmp/sdc1/ mount: /tmp/sdc1: mount(2) system call failed: Function not implemented. # tail /var/log/syslog Jun 30 00:08:05 ToyBox kernel: XFS (sdc1): device supports 4096 byte sectors (not 512) # blockdev --report /dev/sdc* RO RA SSZ BSZ StartSec Size Device rw 256 4096 4096 0 16000900661248 /dev/sdc rw 256 4096 4096 64 16000900608000 /dev/sdc1 Curiously, I noticed that the md devices are being reported as 512-byte sector deivces, and maybe that played a role in how the xfs file system was created on them: # blockdev --report /dev/md* RO RA SSZ BSZ StartSec Size Device rw 256 512 512 0 16000900608000 /dev/md1 rw 256 512 512 0 16000900608000 /dev/md2 So, is that a bug or a feature? I am wondering, how can such misrepresentation possibly be good for performance? And, are we no longer able to mount a data disk outside our unraid server? (For me, that was a big selling point back when I first learned about Unraid.) Any suggestions?

Anyway, they've just declared 5.8 EOL.

That was back in August. At this time it's not so certain that 5.10-stable will be out by the end of the year. So it's very likely they'll go back to the original plan and make 5.9 be the next LTS. In any case, 5.9 has some really cool improvements over 5.8. Worth considering. Not that it matters much though, as by the time 6.9-beta turns into 6.9-release, the kernel will be at 5.14-LTS. :-)

Now that the 5.9 kernel has gone stable, and 5.9 will be the one designated "longterm", not 5.8, then maybe we should try going with the 5.9 series?

By all means, go fund yourself.

And 10 years later I will still not ike it.

You didn't need to bother adding those up -- just read the whole thing as one string, and then compare the two strings from before and after. Same thing though. This thing keeps getting curiouser and curiouser. :-) It begs the question, why I am not seeing this on my server? Can you maybe restart your server, but this time without starting emhttpd, and see if the spinup happens again? Could something (maybe from the UI?) be sending some weird request to the disk that wakes up SAS disks?... Like a smart info request maybe? I'm just speculating.

Now this is something interesting, and we should get to the bottom of it! I don't see that on my server, but then again, my UI is stock vanilla with no plugins, and even custom-crippled a bit. :-) You should definitely try to prove the "no i/o happening" claim. I suggest you make your monitoring script read the device's stat file, and demonstrate that the reading before and after the disk spins up are exactly the same. Now that would be really interesting!

I understand what you are trying to do, and I applaud your efforts. My point is, a disk can spin down for different reasons, including it can decide to spin down all by itself, and it doesn't need to give any explanation about that to the UI. So, if the UI can't make heads or tails of it, then the problem is in the UI. The UI should learn to properly sense the disk status and to display it correctly. I not only think I'm spinning down the disks, I know I am, as I'm watching their status refresh in real time in a ssh window -- basically the same thing that you are trying to watch inside a browser with colored balls, only I have extensively tested my "monitor" script to know that it reflects the real status correctly. Anyway, I'll be watching the progress of this discussion, and I'll chime in if I think that I have something more to contribute. Good luck!

See, I have the feeling that you are not correctly identifying the problem. The way I see it, the problem is not how to spin down disks, the problem is that some buggy scripts in the UI don't know how to properly query a disk without waking it up, and they don't know when to rightfully display a green ball (or whatever other collor). Personally, I rarely use the UI for anything, and on my server disks spin down when they are supposed to, and they stay spun down. From reading the posts in this thread, I have the impression that you are trying to fix things kind of backwards, i.e., you take some info from the UI (that does not match reality) and try to make the disk status match that unreal info from the UI. That is why I suggested that maybe you shouldn't bother, doing it that way, and instead plead with the UI people to fix their UI, if the UI is that important to you. I hope this explaination makes some sense. :-)

Right. But I have a bunch of disks that disregard that setting. Which was the main reason I wrote my script. Anyway, I was only trying to help. For myself, I have a solution that has been working flawlessly on my server for years. If you don't like it -- forget I posted it. Cheers.

It doesn't seem wize to hitch your wagon to something that's been buggy for a very long time. Especially when there's a very easy way to do this yourself -- just read /sys/block/sdX/stat directly, and when you notice that there's been no i/o activity for a certain period of time, then just go ahed and spin down the drive. For example, I am attaching here my own little script that has been faithfully serving me for over five years now. Just disable all spindown stuff in the UI, start my script from your "go" file, and forget about it. (Note, the UI may also be buggy in the way it polls for smart data, thus spinning up your disks, so you may want to look into that too.) #!/bin/bash # spind: disk spin-down daemon copy="Version 3.9 <c> 2020 by Pourko Balkanski" prog=spind #################################################################### MINUTES=${MINUTES:-60} # the number of idle minutes before spindown #################################################################### idleTimeout=$(($MINUTES*60)) # in seconds loopDelay=61 # seconds kill $(pidof -x -o $$ $0) 2>/dev/null # our previous instances, if any [ "$1" = "-q" ] && exit 0 # Don't start a new daemon if called with -q renice 5 -p $$ >/dev/null # renice self log () { logger -t $prog $@ ;} log $copy # Make a list of the disks that could be spun down i=0 for device in /dev/[sh]d[aaa-zzz] ;do if proto=$(smartctl -i $device | grep -iE ' sas| sata| ide') ;then ((i++)) devName[$i]=$device cmdStat[$i]="cat /sys/block/$(basename $device)/stat" devLastStat[$i]=$(${cmdStat[$i]}) devSecondsIdle[$i]=0 devError[$i]=0 # We'll use to flag disks that won't spin down cmdSpinStatus[$i]="hdparm -C $device" cmdStandby[$i]="hdparm -y $device" if grep -iq ' SAS' <<<$proto ;then # Switch from /dev/sdX to /dev/sgN devName[$i]=$(sg_map26 $device) cmdSpinStatus[$i]="sdparm --command=sense ${devName[$i]}" cmdStandby[$i]="sg_start --pc=3 ${devName[$i]}" fi theList+="${devName[$i]} " fi done devCount=$i if [ "$theList" = "" ] ;then log 'No supported disks found. Exiting.' exit 1 fi log "Will spin down disks after $MINUTES minutes of idling." log "Monitoring: $theList" while :;do sleep $loopDelay for i in $(seq $devCount) ;do [ ${devError[$i]} -gt 2 ] && continue # this disk has previously failed to spin down. devNewStat[$i]=$(${cmdStat[$i]}) if [ "${devNewStat[$i]}" != "${devLastStat[$i]}" ] ; then # Some i/o activity has occured since the last time we checked. devSecondsIdle[$i]=0 devLastStat[$i]=${devNewStat[$i]} else # No new activity since we last checked... # ...So, let's check its spin status if ${cmdSpinStatus[$i]} | grep -iq standby ; then devSecondsIdle[$i]=0 else # it's currently spinning let "devSecondsIdle[$i] += $loopDelay" # Check if it's been idling for long enough... if [ ${devSecondsIdle[$i]} -gt $idleTimeout ] ; then # It is time to spin this one down! log "spinning down ${devName[$i]} " ${cmdStandby[$i]} >/dev/null 2>&1 devSecondsIdle[$i]=0 sleep 1 # no need to worry about race conditions here. # Check if the drive actually spun down as a result of our command if ${cmdSpinStatus[$i]} | grep -iq standby ;then devError[$i]=0 else ((devError[$i]++)) [ ${devError[$i]} -gt 2 ] && log "${devName[$i]} fails to spin down." fi fi fi fi done done & disown exit 0 spind-3.9.zip

Do you want to try disabling ACL in Samba config on the server? Add that line in the [global] section of /boot/config/smb-extra.conf nt acl support = No Restart Samba. Re-run your speed tests. Let us know.

Regarding slow Samba, may I make a suggestion? If you are not using ACL, and chances are you are not, then disable that feature in Samba config. That made a HUGE difference on my server, and for the first time ever I was able to saturate my network adapter. Try it out: Add this line in the "Samba extra configuration", see Settings -> SMB -> SMB Extras nt acl support = No (Or just edit /boot/config/smb-extra.conf and add that line in the [global] section.) You can also run a testparm on the command line to verify that the setting is in effect. Restart Samba, and re-run your speed tests. Let us know how it goes. Note: I ran my tests ram disk to ram disk, to eliminate everything else but Samba. I do not know how much this will help with user-shares, as I don't use them. Chances are, user-shares may have separate problems, all of which contribute to the overall network slowness.

I could swear this was a selfie I took like 10 years ago. 😄 As you see, I was young and good-looking back then. Now I'm just good-looking.

@ccruzen LOL... I was about to ask can't you get your own avatar, when I found on archive.org that you've been using this for years. Ooops! :-) I'll get around changing mine next week. (Unless you don't care?) Cheers!

Just for information... I've posted it in the Feature Requests section: https://forums.unraid.net/topic/95981-single-disk-corruption-detection-on-dual-parity-arrays/ On 8/22/2020 at 1:38 PM, limetech said: I'll revisit this topic for 6.10 release Thank you.

See, guys, this whole thing boils down to knowledge. Knowledge about which disk exactly is carrying the mismatched byte at certain position. Knowledge that can't be had with single parity, but can be had with dual parity. It amazes me that some people would not want that knowledge. Like, life is easier without that knowledge -- just assume that the parity is wrong and sync it. Like, if they are suddenly given the knowledge that, say, disk#4 is carrying the corrupted byte at that point, then they would be stumped about what to do with that knowledge. Let me ease the anxiety: You could always chose to do what you have been doing all along -- sync the corrupted byte onto the parity disks. Personally, I would take the other option -- recover the corrupted byte from parity.

Yes, I understand, but that is beyond the scope of the kernel driver. Tools in userspace could be developed to that effect. That is a perfect example to prove my point. Thank you.

Parity protection knows nothing about file systems. (At least it shouldn't) It just adds corresponding bits from all disks to see if the result matches the bit that's on the parity disk, that's all. It shouldn't even know about partitions, but that's a different story. :-)

Yes, in 99% of the cases it will indeed be found that a parity disk is the one that's carrying the wrong byte. You will know that without the need of guessing. You are a moderatror, so you read a lot. You must have seen hundreds of posts over the years that sometimes parrity errors appear for no obvious reason, without any unclean shutdowns. When people start pulling their hair, trying to guess which disk those errors may be coming from, they should all wish we have the feature I am suggesting. :-) Personally, this thing has been bugging me for over 10 years now. I raised these questions back in 2013. But back then we had only single parity. And with that you can only detect the fact that there's a parity error, but you can't determine the position of the error. Now that we have dual parity, we could take full advantage of it, and be able to know the position of the error.

No, I am not suggesting that. I did it like that because it was the only way to do it manually. When done programatically, there are better ways to identify the corrupted disk at a certain byte position. I see that there is some confusion here... When I say "single disk corruption", I am not referring to a whole corrupted disk, I am only talking about a certain byte position at which we have arrived and we found a parity mismatch. At the position of the next parity error, the corruption may or may not be on the same disk as before. It doesn't matter, we are dealing with one byte position at a time. Therefore, all disks may have corruprions in various places, and as long as the corruptions are not at the same byte position, you could recover all disks in one pass. Also, note that we are not destinguishing between data or parity disks, it works the same.