Mark Booth's questions

Having discovered ledctl via Physically Identify the failed hard drive I've been trying to use it indicate a drive to pull from an HP DL380e G8 server running Proxmox, but ledctl locate=/dev/disk/by-id/... does nothing. The blue locate light on the LFF caddy stays resolutely off.

A ledctl -L successfully shows the SAS/SATA controllers:

# ledctl -L
/sys/devices/pci0000:00/0000:00:1f.2 (AHCI)
/sys/devices/pci0000:00/0000:00:01.1/0000:07:00.0 (SCSI)

I've confirmed that the disks are on those controllers:

# ls /dev/disk/by-path/ | grep -v part
pci-0000:00:1f.2-ata-6
pci-0000:07:00.0-sas-phy0-lun-0
pci-0000:07:00.0-sas-phy1-lun-0
pci-0000:07:00.0-sas-phy2-lun-0
pci-0000:07:00.0-sas-phy3-lun-0
pci-0000:07:00.0-sas-phy4-lun-0
pci-0000:07:00.0-sas-phy7-lun-0

It appears that the LSI SAS2308 controller supports SFF-8485 SGPIO, so that shouldn't be a problem, but there was still some suggestion that I might need an sgpio package to get it ledctl to work. However I can't any details of specifically which package I need or whether it needs any configuration.

The answers on other questions suggest it just works out of the box, but these may assume we are using the controller in RAID mode rather than JBOD^†.

^{† This machine was bought as a ZFS file server host.}

Looking through the issues at the Github intel/ledmon issues it looks like there should be some activity in /var/log/ledctl.log when ledctl is run, but on my system all I can see there are logs of attempts to run ledctl without arguments:

# ledctl locate=/dev/disk/by-id/...
# cat /var/log/ledctl.log
May 19 14:08:53   ERROR: missing operand(s)... run ledctl --help for details.

The only other thing IO can think of is that the backplane used by HP doesn't support addressing the LEDs this way.

So,

• Is it possible to use ledctl to control the LEDs on an HP DL380e G8 8xLFF backplane?
• If so, how?
• If not, is there any other way to do what I want?

I have an HP Microserver running OpenMediaVault 2.1.18 (Stone burner), based on Debian GNU/Linux 7 (wheezy).

A few days ago, I needed to copy a large number of files from a USB drive, formatted with NTFS. I connected it, mounted it and started the copy and left it to complete.

A day later, I find that it has copied hardly anything, and my NAS performance had tanked. Investigating, I find that page and buffer cache are now taking up over 3/4 of system memory (together these normally take less than 10%) and the ZFS ARC is now squeezed into the remaining memory (less than 1/4 it's normal size).

When I realised what was wrong, I stopped the copy, unmounted and unplugged the drive and very rapidly the caches went back to their normal size, then the ARC started to fill itself back to it's normal level.

So, if I need to do do more direct copies in the future, how do I prevent mounting ntfs drives causing large amounts of memory to be consumed, starving my ZFS ARC of the memory it needs?

Note: I tried running echo 3 > /proc/sys/vm/drop_caches (to "free pagecache, dentries and inodes" according to man 5 proc), as shodanshok suggested, but this also flushed my ARC (except the memory needed to cache the L2ARC header). My system thus had lots of free memory, but since things are only cached in either ARC or L2ARC, my system then spent ages thrashing the drives to repopulate the ARC, not a desirable state of affairs.

In this image, you can see the ZFS starvation at the start of the 5th, when I started my ntfs copy, things returning to normal when unmounting the ntfs drive early on the 6th, and then finally the ARC being cleared (and rebuilt) after using drop_caches, on the afternoon of the 7th.