Pourko

Members
  • Content Count

    72
  • Joined

  • Last visited

Community Reputation

3 Neutral

About Pourko

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Anyway, they've just declared 5.8 EOL.
  2. 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. :-)
  3. 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?
  4. And 10 years later I will still not ike it.
  5. 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.
  6. 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!
  7. 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 wat
  8. 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 s
  9. 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.
  10. 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
  11. 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.
  12. 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.
  13. 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.
  14. @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!