MrMKHR

Members
  • Posts

    14
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

MrMKHR's Achievements

Noob

Noob (1/14)

0

Reputation

  1. Found a possible solution in the proxmox forum. Basically posted the same there, but since it took me a while to actually find it I'm duplicating it here. https://forum.proxmox.com/threads/high-cpu-load-for-windows-10-guests-when-idle.44531/ The hpet setting seems to fix it for me. After setting it to yes, everything seems back to pre-1803 levels. edit: fixed link
  2. I'm not sure on how you went on with this, but a word of warning: It looks like you opted to get a complete package from startssl, including a private key created by them. Most people might think of this as a mood point, however this little detail compromises everything. I'll leave it here for everyone else going through the guide. http://security.stackexchange.com/questions/16685/what-can-an-attacker-do-with-a-stolen-ssl-private-key-what-should-the-web-admin I think you have the option to provide a csr to startssl. That csr would be created by you, with your private key that you created yourself on your machine and WILL NOT expose to anyone at any time. If they don't provide that option, other free services do.
  3. sorry for double posting. I'm back with more information. - It's definately not preclear. I startetd preclear in the morning, watched my drives during the day and didn't see anything happen. preclear went on and startetd to write without accessing the array. - There deinately is something else going an. and from the read count it seems to be a lot (comparing with read count of me watching a movie). I tried to find out who is accessing the discs (via lsof) today and have two candidates: a) "find" or b) smartctl. since the read count is increasing by more than 1.000.000 i'd like to know what is causing it (and maybe prevent it). I'm not sure why find is running and why it seems to be touching every single file (at least as far as I could observe within the timespan I watched via lsof). To check if folder caching is involved I deactivated it, but to no avail... Could anybody elaborate on what and why could cause this behaviour? I'll try to access the box remotely during the week to do further checks. EDIT: forgot to add that find is accessing via /mnt/user/disk*. seen in lsof like this:
  4. @ itimpi: great, i'll try to check if it occurs again. @ bjp999: I'm pretty sure I understood. It can't be the mover because I still saw the read count rising the next morning. I know for sure that I didn't add anything in the cache the night before, I rebooted before starting the prelear (so the count should have been nearly zero) and of course I checked manually checked if its running (both via checking the status in dynamix and checking the content on the cache drive). the only way this could be related to the mover is if the mover was still running while I was watching, but this was NOT the case. I also don't see how this could be caused by the temp file. Maybe I'm really missing something here. I checked with both, unmenu and dynamix and both display the same, so both would need to have the same bug. but even if this was the case, preclear was still running and updateing the file. I stopped it manually AFTER checking everything else. As I said, maybe I missed your point regarding the temp file, but the problem is not about the status not updateing but rather about TWO drives that shouldn't even be spinning reading data somehow. btw thanks for the ongoing support. I'll try to solve this today and give feedback. I'm away from tomorrow so I hope I can leave preclear running and have the drive ready by next weekend...
  5. I'm sorry, I think I must have missed to explain things properly. - I started the preclear on sdf. preclear correctly displayed all information and started. - The next morning I checked the status and saw that not only preclear was running but also that the read count on TWO ARRAY DRIVES increased. those two drives weren't read by me (or any other client). I'm sure of this because no machine beside the one i used at that moment was running. Also, the active streams screen didn't show anything. Since I was able to still see the read count climb even further I am also sure that this wasn't just some access during the night thatI forgot about. - I was able to see this happening twice. The first time I saw it in dynamix, the second time I also had unmenu installed and it displayed the same information (thats what you see in the screenshots). Hence, I can say this isn't a display bug. - Of course the read count could be because of something different than preclear, but I don't want to risk waiting until preread is done and see the write count increase on my array drives. Hence, I was looking for a way to check what exactly is accessing the drive. - Meanwhile, I did a little research myself and came up with lsof. But I don't quite understand how to read the result. I guess "lsof | grep /dev/sd" isn't enough since it isn't showing whats access via /mnt/user. So, is it enough to grep for those two?
  6. sorry, AHCI ofc. Short trip to the BIOS and its sdf instead of hda now. However, I still think this is NOT an UI thing: It didn't show up directly after starting the preclear... Any hints to prevent the data loss by preclear are much appreciated
  7. i will check the bios settings regarding ACPI. Regarding the temp file: The problem occured during the preclear, so it isn't associated to not deleting the file. Also, the server was rebooted right before the pre-clear. Actually, for this to be an UI related bug, the UI would have to somehow parse the "/dev/hda" label preclear is producing and map it to two different drives (sdd and sde) AND continously update both drives' (not at the same rate but with an nearly even distribution) read count. So, is there any definite way for me to check which hdd is being used (as I don't trust this to just be an UI bug)?
  8. the problem being that there apperently was NO activity on the drive that was supposed to be clreared, but instead on two array drives. I think I should have made clear that all those reads (on the array) were NOT coming from me. so either this is a display bug in dynamix or preclear actually was using the wrong disk.
  9. Hey all, Yesterday I got my first 6TB drive. Previously, I never precleared. Bad thing, I know. So i tried to start the preclear and at first everything seemed fine. The prompt gave me the right describtion, size etc. Afterwards, I went sleeping because it was late. Maybe I should have paid more attention because the next morning I noticed this: Now, I was really afraid because apparently the drive that was undergoing was spun down while two array drives were spun up. I also noticed the read count was increasing. Could anyone give me any advice on what my next steps should be as I'm afraid it would go on with writing to those two disks after the read step. Oh, another "detail": the new drive is connected via eSATA in an external enclosure. EDIT: To summarize the whole topic: it wasn't preclear, bt most probably cache dirs. cache dirs seems to behave badly and I really ned to find out what is happening (and why), but I need to do that later because I can't find the time right now, hence I'll mark this as solved.
  10. Hey all, I just set up a second server that should become an duplicate of my existing server. the thing is, i can do the initial sync via LAN (which i'll do in a few minutes), but afterwards the second Server will be placed in another building. the connection on one of the sites is very bad, so i can't do an online sync. could anyone come up with a method to manually sync both using an external drive? I'm not sure something _very_ simple like filtering files via timestamp would be enough. I only fill the primary server using a windows client... Ideas?
  11. 1) sorry, no preclear. fresh from the package into the unraid box and added to the array. of course i can run some tests now. 2) not _directly_ before, but i always do a backup after i do modifications so the previous backup has the old config. 3 and 4) see attachments. thanks for the help. logs.zip
  12. Hi Guys, might be obvious to most, but I'm not sure on it and couldn't verify via the board search: I have a really mixed setup running. each drive from a different series. 4TB parity, 1x 1TB, 1x2TB, 2x3TB. Yesterday I replaced the 1TB drive with a 4TB one. The rebuild is running at ~35MB/s but before parity checks were running at 90MB/s. Now the question: Of course rebuild involves writing so it won't be as fast as a plain check, but is 90MB/s vs 35MB/s acceptable or is there a problem with the new drive? Just want to check first before hunting for a problem that might not even exist in the first place... Oh, just in case anyone needs it: the new drive is a WD40EURX. UnRAID 5.0, HP N54L (Turion DualCore 2.2Ghz)