lkn

Members
  • Posts

    5
  • Joined

  • Last visited

Recent Profile Visitors

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

lkn's Achievements

Noob

Noob (1/14)

0

Reputation

  1. I cannot see a FANA section, only FAN1234. My FAN4 sensor is showing up as FAN4 and not FANA, even though the motherboard manual says it should. On my old board, I know FAN4 did show up as FANA and I did see the section under the Fan Control tab. Though I haven't used the fan control functionality of your plugin at the time. Is there any way for me to override this and have FAN4 be treated as FANA? Here is what shows up at the sensor readings. As you can see, it clearly says 'FAN4'. At that point I have manually changed the duty cycle of the peripheral zone to 24 (<50%). Here is what happens once I set it to 64 (100%): All the fans attached to FAN4 are spinning twice as fast while the other fans speeds are unchanged. I think it's just the sensor name "FAN4" that is preventing it from being recognized as being part of a separate cooling zone.
  2. Hi, I have a shiny new SuperMicro X10SDV-TLN4F board. The PCB is revision 2.00 so it has fan header FAN4. According the motherboard manuel this one is supposed to show up as FANA in IPMI but this is not the case. The previous board I'm replacing is the SuperMicro X10SDV-4C-TLN4F board. Also revision 2.00 and there FAN4 did show up as FANA in IPMI. Updating the BIOS and BMC to the latest version did not magically fix this problem. I've confirmed with IPMI raw commands that FAN4 is indeed on a separate cooling zone. Changing the duty of cycle of the peripheral zone slowed down only the fans attached to FAN4. Yet this plugin still lumps it together with the other fans under FAN1234, probably because of the sensor name. Is there any way I can get the plugin to configure FAN4 on a separate cooling zone? Or do I just have a faulty board? Thanks
  3. Hi bonienl, the s3 plugin no longer shuts down my system ever since updating to the latest version. In the syslog I see nothing but "Disk activity ongoing" entries, every time for the first disk in my array, namely the parity disk. The changelog indicated "disk state" is now considered in the disk activity check. Does this mean the disks have to be spun down in order to meet the requirements? From my observations that's exactly what happens. If this is intended, then this is a breaking change for me and anyone else who does not allow one or more of the disks considered to spin down. It also makes little sense for it to still check disk I/O as well if that's the case. A better solution would be to fall back on disk I/O if a particular disk is set to never spin down or add an option so we can change this behavior. But if this is unintended, then I'm guessing this block is responsible: diskio=($(grep -Pho "^$dev \K\d+" /dev/shm/1 /dev/shm/2)) if [[ -n $active || ${diskio[0]} != ${diskio[1]} ]]; then result=1 break; fi You probably meant to do something like this: if [[ -z $active ]]; then continue; fi diskio=($(grep -Pho "^$dev \K\d+" /dev/shm/1 /dev/shm/2)) if [[ ${diskio[0]} != ${diskio[1]} ]]; then result=1 break; fi That would fix the issue.
  4. Ah, I should have looked at the stickies first. I see there are clear and simple procedures for adding the new ones and then removing the old one from a RAID1 cache pool. Thanks!
  5. Hi guys, At the moment I have a 480gb ssd mounted as a cache drive. I wish to replace this drive with two new 512gb ssd drives. What would be the best way to do this? I thought about simply adding the new drives and have a 3-drive cache pool set up as RAID1. After the build I'd simply remove the old 480gb ssd drive. Is it really this simple? How will unraid react if I unassign a drive belonging to a RAID1 array? How will I grow the array to utilize 512gb instead of 480gb? Or is it better to play it safe and use the tried-and-true method of backing up, restoring, recreating docker image, reinstalling dockers etc...? Thanks