Jump to content

Marc_G2

Members
  • Content Count

    32
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Marc_G2

  • Rank
    Advanced Member
  1. Thanks, I will give your version a try. I wish there was dedicated forum threads for each these plugins.
  2. So I'm still having a problem where S3 Sleep is erroneously detecting drive activity (and then not going to sleep). What is criteria for hard drive activity occurring? I assumed it was checking if the drives were spun up. But that doesn't appear to be the case. At the moment, my best guess of the root cause is one of my windows PCs (that remain on most of the time) is somehow causing the issue. Anyone have an idea? I've attached a screenshot of plugin config. EDIT. I wanted to have this image as just a clickable item you could expand. Is that not possible?
  3. No any CPU activity spikes I've seen have always been temporary (and I assume are due to normal activity). So I don't believe I've had that particular issue. Based on the debug logs, it's always because of detected array activity. But I still haven't confirmed what's been pinging my server so much.
  4. Thanks, I forgot about that option. The system ran throughout the night again and according to the syslog, it was detecting drive activity. I'll try disabling Cache Directories to see if that fixes the issue. Usually when I've encountered this issue, unRAID would show all drives being spun down when I checked in the morning. So I didn't think it was the plugin misbehaving.
  5. S3 Sleep, Unreliable activation. I have my unRAID server setup to go to sleep after a period of inactivity. Most of the time it works as expected. But frequently I would leave the server untouched over night and find out the next morning it never automatically went to sleep. Whether it works correctly seems random. Do you have an idea on what could be causing the issue? The only other plugins that run automatically daily are Dynamix SSD TRIM and Cache Directories. I don't imagine those being the issue.
  6. I have my unRAID server setup to go to sleep after a period of inactivity. Most of the time it works as expected. But frequently I would leave the server untouched over night and find out the next morning it never automatically went to sleep. Whether it works correctly seems random. Does anyone have an idea on what could be causing the issue? The only other plugins that run automatically daily are Dynamix SSD TRIM and Cache Directories. I don't imagine those being the issue. unRAID 6.7.2 MSI X270 Gaming Plus Ryzen 3600X
  7. You did confirm the performance was bad with multiple games right?
  8. Some Googling showed that the error could be result of corrupt file system. I ran Windows Chkdsk and it found no errors. Against my better judgement, I decided to delete the empty partition shown in the screenshot and now it can't boot properly. I guess I will do another fresh install of windows.
  9. UPDATE. I ended up formatting the SSD to XFS, and the problem went a way. The drive was originally formatted to NTFS by Windows when I created the VM. Perhaps that caused the issue. ORIGINAL POST_________________________ I've attached my system log. I believe there's an issue with my UD mounted SSD that's causing my system log to get filled up with this message below. Most recently, I created a new Windows 10 VM while passing though the SSD. I'm guessing that's related. I also recently enabled ACS override to pass though a USB card. Help would be greatly appreciated. Nov 16 10:01:33 NAS-NG ntfs-3g[6394]: ntfs_mst_post_read_fixup_warn: magic: 0x00000000 size: 4096 usa_ofs: 0 usa_count: 0: Invalid argument Nov 16 10:01:33 NAS-NG ntfs-3g[6394]: Index buffer (VCN 0x0) of directory inode 86039 has a size (24) differing from the directory specified size (4096). Nov 16 10:01:33 NAS-NG ntfs-3g[6394]: ntfs_mst_post_read_fixup_warn: magic: 0x00000000 size: 4096 usa_ofs: 0 usa_count: 0: Invalid argument Nov 16 10:01:33 NAS-NG ntfs-3g[6394]: Index buffer (VCN 0x0) of directory inode 86096 has a size (24) differing from the directory specified size (4096). Nov 16 10:01:33 NAS-NG ntfs-3g[6394]: ntfs_mst_post_read_fixup_warn: magic: 0x00000000 size: 4096 usa_ofs: 0 usa_count: 0: Invalid argument Nov 16 10:01:33 NAS-NG ntfs-3g[6394]: Index buffer (VCN 0x0) of directory inode 83330 has a size (24) differing from the directory specified size (4096). Nov 16 10:01:33 NAS-NG ntfs-3g[6394]: ntfs_mst_post_read_fixup_warn: magic: 0x00000000 size: 4096 usa_ofs: 0 usa_count: 0: Invalid argument Nov 16 10:01:33 NAS-NG ntfs-3g[6394]: Index buffer (VCN 0x0) of directory inode 83338 has a size (24) differing from the directory specified size (4096). nas-ng-syslog-20191116-1502.zip nas-ng-diagnostics-20191116-1526.zip
  10. I created a new VM while passing though the SSD. Sustained write speed is now 200+ MB/s. Definitely better, but still not close to bare metal. Crystal diskmark gave bad results due to caching. For perspective, this is what Space Invader One got for a Vdisk. He had similarly bad sequential write speeds. https://youtu.be/QaB9HhpbDAI?t=15m44s Should I still configure the disk to as a "thin provisioned drive"?
  11. I believe the config is correct (see above). The media type says it's a "Solid state drive" and doesn't say it's a thin provisioned drive. So I'm not sure where I went wrong.
  12. Well I managed to get VM booting with VirtIO again. I needed to initialize my newly created disk in Windows Disk Management prior to switching the primary disk to use VirtIO. A quick file copy test shows sustained writes are still less than 100 MB/s. For some reason, Windows won't let me defragment the SSD. It says "Optimization not available" on its status. I'm pretty sure the XML is correct: <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback' discard='unmap'/> <source file='/mnt/disks/Crucial_CT525MX300SSD1_163213963944/Windows 10/vdisk1.img'/> <backingStore/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <alias name='virtio-disk2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
  13. I will give this a try before trying to pass though the SSD. Although I was only using 50/500 GB I had available.
  14. I noticed I was getting poor SSD (Crucial MX300) write performance (about 100 MB/s or less) in my Windows 10 VM. The SSD was mounted using Unassigned Devices. I noticed Windows referred to the VirtIO drive as a SCSI device. So I tried changing "Primary vDisk Bus" to SATA to see if it would help. That didn't help, and it ended up causing other issues including stuttering/cracking audio. The MSI fix doesn't seem to work. Switching back to VirtIO doesn't allow Windows to boot. What performance should I expect from my SSD? Was my problem a VirtIO configuration issue? EDIT. Will try a fresh install and passing though the SSD.
  15. Nice. It looks like that fixed it for me as well. I actually saw that MSI thread as well. But I couldn't figure out what he was trying to say so I quickly moved on lol.