ping -D -s 8972 <IP>

Для установки hpssacli нужно переделать vib файл а именно удалить из него проверку на биос вендора HP, для этого потребуется перепаковать файл vib

распаковываем

ar vx file.vib

Далее редактируем descriptor.xml, удаляем строки

<hwplatform vendor=«HP»/>

<hwplatform vendor=«Hewlett-Packard Company»/>

<hwplatform vendor=«Hewlett-Packard»/>

<hwplatform vendor=«hp»/>

Собираем vib обратно

ar -r hpssacli_n.vib hpssacli descriptor.xml sig.pkcs7

Закидываем на хост и ребут

/tmp # esxcli software vib install -f -v hpssacli_n.vib
Installation Result
Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
Reboot Required: true
VIBs Installed: Hewlett-Packard_bootbank_hpssacli_2.30.6.0-6.0.0.2159203
VIBs Removed:
VIBs Skipped:

Установлено: VMware-ESXi-5.5.0-Update3-3568722-HPE-550.9.6.5.9-Dec2016.iso

Версия драйвера дисков: — scsi-hpvsa-5.5.0.100-1OEM.550.0.0.1331820

Как выяснилось, HP что-то испортили в драйвере дисковой подсистемы для ESXi 5.5 и работа с дисками стала … скажем так, не очень эффективной. Более того, как выяснилось позже, такая же проблема существует и в гипервизорах ESXi 6.0/6.5 от HPE.

Насколько не эффективно? Результаты замеров в статье. Сразу скажу — оглушающие.

Пообщавшись со знакомыми и покопав Интернет было выяснено, что всему виной и правда, драйвер, который HPE включила в свой кастомный образ с установщиком гипервизора ESXi 5.5 и более поздних версий.

Но, решение этой проблемы есть. Совместными усилиями Интернет-сообщества (https://homeservershow.com) был найден драйвер, который реально ускоряет работу с дисками в HP Microserver Gen8.

Версия драйвера: scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820

Сам драйвер можно легально, бесплатно и без регистрации, скачать c сайта HPE:
https://support.hpe.com/hpsc/swd/…b1dfc5314e02bc01b1436b
Type: Driver — Storage Controller
Version: 5.5.0-88.0(9 Sep 2014)
Operating System(s): VMware vSphere 5.5
File name: scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib (707 KB)

Осталось его установить. Как это сделать, описано ниже.

В первую очередь проверяем версию установленного драйвера и, если отличается, то заменяем на правильный.

А) Заходим в консоль ESXi хоста через PuTTY под именем root и запускаем команду

esxcli software vib list | grep scsi

Вот, что было у меня до смены драйвера

~ # esxcli software vib list | grep scsi

То есть. Не тот. Почему? А вот, что показал тест производительности. Не то чтобы тест, но из приведенных команд видно, что тестируется.

Выполняем следующие команды из консоли ESXI:

cd /vmfs/volumes/[datastore]<br>time dd if=/dev/zero of=tempfile bs=8k count=1000000

Примечание: Не забудьте поменять [datastore] на имя вашего реального DataStore.

Получаем результат:
1000000+0 records in
1000000+0 records out
real 14m 12.62s
user 0m 12.23s
sys 0m 0.00s

Вроде бы не плохо, да?

Для сравнения, в той же конфигурации, но с установленным, ESXi 5.1U3 получаем примерно следующее:
1000000+0 records in
1000000+0 records out
real 17m 25.62s
user 0m 7.23s
sys 0m 0.00s

То есть, налицо видимое улучшение по сравнению с предыдущей версией гипервизора. Но, вам придется поверить мне на слово, а потом посмотреть на совсем другой результат. Дочитайте до конца.

Итак, приступаем к смене драйвера.

Процедура достаточно простая. Предполагается, что нужный драйвер Вы уже скачали с сайта HP, по приведенный ранее ссылке.

1. Останавливаем все запущенные VMs
2. Если не включено, включаем ssh
3. Копируем файл «scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib» to /tmp (например, с помощью WinSCP)
4. Подключаемся к консоли гипервизора ESXi с помощью PuTTY (с правами root, естественно)
5. Меняем текущую папку на ту, куда положили файл, то есть на папку /tmp
   

   cd /tmp

6. Копируем vib-файл в папку из которой он будет инсталлирован
   

   cp scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib /var/log/vmware/

7. Переводим гипервизор в Maintenance Mode
   

   esxcli system maintenanceMode set --enable true

8. Удаляем текущий драйвер дисковой подсистемы
   

   esxcli software vib remove -n scsi-hpvsa -f

9. Инсталлируем правильный драйвер scsi-hpvsa-5.5.0-88OEM из файла

   esxcli software vib install -v file:scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib --force --no-sig-check --maintenance-mode

10. Перезапускаем ESXi, отключаем Maintenance Mode, запрещаем ssh (если нужно) и запускаем свои виртуальные машинки.

Примечание: Отключить Maintenace Mode можно из клиента или из консоли, командой:

esxcli system maintenanceMode set --enable false

Все просто? Да, просто.

Но ведь всегда хочется убедиться, что автор не наврал.

Проверяем, что версия драйвера изменилась.

esxcli software vib list | grep scsi

Да. Изменилась на правильную.

А скорость? Не обманули? Проверяем! Что я и сам сделал. Запустил, повторно, тест производительности. Результат меня, мягко говоря, ошеломил

cd /vmfs/volumes/[datastore]<br>time dd if=/dev/zero of=tempfile bs=8k count=1000000

Это в СЕМЬ раз быстрее, чем с предыдущим драйвером и почти в 9 раз быстрее чем на ESXI 5.1U3

На форуме пользователи подтвердили, что примерно такой же, не правильный, драйвер устанавливается и при инсталляции ESXi 6.0 и 6.5. И замена его на версию scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820 приводит к такому же ускорению работы дисковой подсистемы.

После добавления очередей запускаем

./usr/local/fop2/autoconfig-buttons.sh

php /var/www/html/panel/admin/update_conf.php 1

For example. Open a root shell

mkdir /tmp/etc_asterisk
cp -a /etc/asterisk/* /tmp/etc_asterisk 
 

Apply changes in FreePBX and then in the shell

diff -r /etc/asterisk/ /tmp/etc_asterisk/ 

Для сброса закидывает всю папку linux\x64 и выполняем

chmod +x IPMICFG-Linux.x86_64; ./IPMICFG-Linux.x86_64 -fd

Ждем рестарта SMC и после этого входим по DHCP с логином паролем ADMIN ADMIN

Устанавливаем пакеты и компилим с исходников

sudo apt-get install dkms build-essential linux-headers-$(uname -r) git

git clone git://github.com/facebook/flashcache; cd flashcache

make -f Makefile.dkms

make install

После этого подгружаем модуль

modprobe flashcache

Дальше добавлем кеш к диску sdaX в режиме writeback

sudo flashcache_create -p back fcache /dev/sdbX /dev/sdaX

Для проверки попаданий в кеш вводим

dmsetup status cachedev

Для размонтирования кеша с выгрузкой грязных данных используем

dmsetup remove cachedev

Файл /etc/fstab не менялся, т. к. кеширование делается на уровне md-устройтва, поєтому домашний каталог доступен без бубнов и танцев сразу после загрузки системы.

Твики в sysctl.conf:
dev.flashcache.sda+md2.fallow_delay = 240
dev.flashcache.sda+md2.fast_remove = 1
dev.flashcache.sda+md2.reclaim_policy = 1
dev.flashcache.sda+md2.skip_seq_thresh_kb = 1024

Убрать кеширование.
1. umount /home
2. sysctl -w dev.flashcache.sda+md2.do_sync=1
(может занять продолжительное время для записи данных на медленный диск)
3. vgchange -an vg1
3. dmsetup remove ssd
4. flashcache_destroy /dev/sda

Теперь логический раздел vg1-home можно примонтировать без SSD кеша
5. vgchange -ay vg1
6. mount /dev/mapper/vg1-home /home

Ставим munin

Шаг 1. Установка Munin-master и Munin-node

Установить Munin можно из стандартных репозиториев операционной системы :

sudo apt-get update
sudo apt-get install munin
sudo apt-get install munin-node

Шаг 2. Настройка Munin-master

Откроем конфигурационный файл Munin:

nano /etc/munin/munin.conf

Для начальной настройки необходимо изменить только имя хоста, которое будет выводиться в графиках. Для этого в секции конфигурационного файла «# a simple host tree» отредактируем строку

[localhost.localdomain]

Имя хоста можно указать, например, так:

[srv-01.example.com]

 Вот и всё.  Сохраняем внесённые изменения и выходим из текстового редактора.

Шаг 3. Настройка Munin-node

Как и при настройке Munin-master, для начала необходимо открыть конфигурационный файл :

nano /etc/munin/munin-node.conf

В файле нужно найти строку

#host_name localhost.localdomain

Она нужна для того, чтобы изменить имя хоста. Именно её потребуется отредактировать — например, так:

host_name srv-01.example.com

Обратите внимание, что строку нужно раскомментировать (удалить символ # в начале).

Управление плагинами

Чтобы посмотреть список доступных плагинов, необходимо сделать листинг директории /etc/munin/plugins

ls -l /usr/share/munin/plugins/

Для установки плагина нужно создать на него символическую ссылку.

Перейдём в директорию для установленных плагинов.

cd /etc/munin/plugins/

Установим какой-нибудь плагин (в нашем примере это плагин для DNS-сервера Bind):

ln -s /usr/share/munin/plugins/bind9

После добавления всех необходимых плагинов перезапустим Munin-node для примерения изменений:

service munin-node restart

Шаг 4. Настройка доступа к Munin через Apache и Nginx

Результаты мониторинга Munin отображает в виде графиков. Для этого потребуется HTTP-сервер  —  например, Apache или Nginx.

Настройка доступа к Munin через Apache

Для настройки доступа к Munin через Apache необходимо в конфигурацию любого виртуального хоста (в то числе стандартного) внести директиву <Location /munin>

Для этого в файл виртуального хоста потребуется вставить следующие строки

<Location /munin>
    AuthType Basic
    AuthName «Munin Statistics»
    AuthUserFile /etc/munin/.passwd
    Require valid-user
</Location>

После внесения изменений Apache нужно будет перезапустить:

service apache2 restart

Настройка доступа к Munin через Nginx

Для настройки доступа к Munin через Nginx также понадобится внести изменения в конфигурацию любого виртуального хоста:

location /munin {
    alias /var/www/munin;
    autoindex on;
    auth_basic «Munin Statistics»;
    auth_basic_user_file /etc/munin/.passwd;
}

Чтобы настройки вступили в силу, Nginx нужно будет перезагрузить.

service nginx restart

Шаг 5. Создание файла паролей

По завершении настройки создадим файл с паролями пользователей, имеющих доступ к Munin.

Для этого выполним следующую команду:

htpasswd -c /etc/munin/.passwd user

После выполнения данной команды будет предложено два раза ввести пароль от пользователя, после чего файл будет записан. В этой команде можно заменить user на любое удобное имя пользователя.

В конфиге для Nginx ставим

alias /var/cache/munin/www;

После этого добавляем модуль flashcache

wget https://raw.github.com/pkhamre/flashcache-munin/master/flashcache_stats

chmod +x flashcache_stats;mv flashcache_stats /usr/share/munin/plugins/; ln -s /usr/share/munin/plugins/flashcache_stats /etc/munin/plugins/

Установка для дебиан

aptitude install flashcache-dkms flashcache-utils
modprobe flashcache

Установлено: VMware-ESXi-5.5.0-Update3-3568722-HPE-550.9.6.5.9-Dec2016.iso

Версия драйвера дисков: — scsi-hpvsa-5.5.0.100-1OEM.550.0.0.1331820

Как выяснилось, HP что-то испортили в драйвере дисковой подсистемы для ESXi 5.5 и работа с дисками стала … скажем так, не очень эффективной. Более того, как выяснилось позже, такая же проблема существует и в гипервизорах ESXi 6.0/6.5 от HPE.

Насколько не эффективно? Результаты замеров в статье. Сразу скажу — оглушающие.

Пообщавшись со знакомыми и покопав Интернет было выяснено, что всему виной и правда, драйвер, который HPE включила в свой кастомный образ с установщиком гипервизора ESXi 5.5 и более поздних версий.

Но, решение этой проблемы есть. Совместными усилиями Интернет-сообщества (https://homeservershow.com) был найден драйвер, который реально ускоряет работу с дисками в HP Microserver Gen8.

Версия драйвера: scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820

Сам драйвер можно легально, бесплатно и без регистрации, скачать c сайта HPE:
https://support.hpe.com/hpsc/swd/…b1dfc5314e02bc01b1436b
Type: Driver — Storage Controller
Version: 5.5.0-88.0(9 Sep 2014)
Operating System(s): VMware vSphere 5.5
File name: scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib (707 KB)

Осталось его установить. Как это сделать, описано ниже.

В первую очередь проверяем версию установленного драйвера и, если отличается, то заменяем на правильный.

А) Заходим в консоль ESXi хоста через PuTTY под именем root и запускаем команду

esxcli software vib list | grep scsi

Вот, что было у меня до смены драйвера

~ # esxcli software vib list | grep scsi

То есть. Не тот. Почему? А вот, что показал тест производительности. Не то чтобы тест, но из приведенных команд видно, что тестируется.

Выполняем следующие команды из консоли ESXI:

cd /vmfs/volumes/[datastore]<br>time dd if=/dev/zero of=tempfile bs=8k count=1000000

Примечание: Не забудьте поменять [datastore] на имя вашего реального DataStore.

Получаем результат:
1000000+0 records in
1000000+0 records out
real 14m 12.62s
user 0m 12.23s
sys 0m 0.00s

Вроде бы не плохо, да?

Для сравнения, в той же конфигурации, но с установленным, ESXi 5.1U3 получаем примерно следующее:
1000000+0 records in
1000000+0 records out
real 17m 25.62s
user 0m 7.23s
sys 0m 0.00s

То есть, налицо видимое улучшение по сравнению с предыдущей версией гипервизора. Но, вам придется поверить мне на слово, а потом посмотреть на совсем другой результат. Дочитайте до конца.

Итак, приступаем к смене драйвера.

Процедура достаточно простая. Предполагается, что нужный драйвер Вы уже скачали с сайта HP, по приведенный ранее ссылке.

1. Останавливаем все запущенные VMs
2. Если не включено, включаем ssh
3. Копируем файл «scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib» to /tmp (например, с помощью WinSCP)
4. Подключаемся к консоли гипервизора ESXi с помощью PuTTY (с правами root, естественно)
5. Меняем текущую папку на ту, куда положили файл, то есть на папку /tmp
   

   cd /tmp

6. Копируем vib-файл в папку из которой он будет инсталлирован
   

   cp scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib /var/log/vmware/

7. Переводим гипервизор в Maintenance Mode
   

   esxcli system maintenanceMode set --enable true

8. Удаляем текущий драйвер дисковой подсистемы
   

   esxcli software vib remove -n scsi-hpvsa -f

9. Инсталлируем правильный драйвер scsi-hpvsa-5.5.0-88OEM из файла

   esxcli software vib install -v file:scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib --force --no-sig-check --maintenance-mode

10. Перезапускаем ESXi, отключаем Maintenance Mode, запрещаем ssh (если нужно) и запускаем свои виртуальные машинки.

Примечание: Отключить Maintenace Mode можно из клиента или из консоли, командой:

esxcli system maintenanceMode set --enable false

Все просто? Да, просто.

Но ведь всегда хочется убедиться, что автор не наврал.

Проверяем, что версия драйвера изменилась.

esxcli software vib list | grep scsi

Да. Изменилась на правильную.

А скорость? Не обманули? Проверяем! Что я и сам сделал. Запустил, повторно, тест производительности. Результат меня, мягко говоря, ошеломил

cd /vmfs/volumes/[datastore]<br>time dd if=/dev/zero of=tempfile bs=8k count=1000000

Это в СЕМЬ раз быстрее, чем с предыдущим драйвером и почти в 9 раз быстрее чем на ESXI 5.1U3

На форуме пользователи подтвердили, что примерно такой же, не правильный, драйвер устанавливается и при инсталляции ESXi 6.0 и 6.5. И замена его на версию scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820 приводит к такому же ускорению работы дисковой подсистемы.

Разбивка в installimage

SSD: так как он первый, то закомментирован. Остальные секции
DRIVE: переименованы по номерами на 1 и 2.

SWRAIDLEVEL = 1

( по умолчанию на 3-х пытается создать 5-й RAID)

PART swap swap 32G
PART /boot ext3 512M
PART lvm vg0 all
LV vg0 vz /vz ext4 600G
LV vg0 root / ext4 all

Далее, в соответствии с установщиком. Нажимаем f10 и enter.

После загрузки сервера в обычном режиме с установленным чистым Centos, ставим OpenVZ. Установка описана здесь.

Теперь начинается самое интересное.

Установка flashcache

К сожалению, это не быстрый способ установки. Возможно, это из-за OpenVZ ядра. Мануал всего из двух строчек:

1) Подключаем репозиторий

rpm -Uvh http://elrepo.reloumirrors.net/elrepo/el6/x86_64/RPMS/elrepo-release-6-4.el6.elrepo.noarch.rpm

2) И устанавливаем

yum -y install kmod-flashcache flashcache-utils

На момент написания статьи было ядро OpenVZ rhel6-2.6.32 версии 042stab074.10.

Так как для сборки FlashCache требуются некоторые внутренние заголовочные файлы, которые не входят в состав пакета kernel-headers/devel, требуется загрузить и установить полный код ядра. Нам же не хватало vzkernel-headers.

yumdownloader —source kernel-`uname -r`
rpm -ivh kernel-`uname -r`.src.rpm

Далее скачиваем и устанавливаем:

git clone https://github.com/facebook/flashcache.git

cd flashcache

make -f Makefile.dkms

esxcli storage core device smart get -d t10.ATA_____SG9XCS1F50GMIBM______43W7729_59Y1873IBM_____________501010LJ

Parameter Value Threshold Worst
—————————————  — -—— -—
Health Status N/A  N/A  N/A
Media Wearout Indicator N/A  N/A  N/A
Write Error Count N/A  N/A  N/A
Read Error Count N/A  N/A  N/A
Power-on Hours N/A  N/A  N/A
Power Cycle Count N/A  N/A  N/A
Reallocated Sector Count N/A  N/A  N/A
Raw Read Error Rate N/A  N/A  N/A
Drive Temperature N/A  N/A  N/A
Driver Rated Max Temperature N/A  N/A  N/A
Write Sectors TOT Count N/A  N/A  N/A
Read Sectors TOT Count N/A  N/A  N/A
Initial Bad Block Count N/A  N/A  N/A

Для полуяения полного отчета ставим пакет

1. Download
2. Copy the VIB to the /tmp/ directory of an ESXi host
3. SSH to the ESXi host
4. Set the VIB acceptance level to CommunitySupported
5. # esxcli software acceptance set —level=CommunitySupported
6. Install the package (Maintenance Mode or Reboot is not required)
7. #esxcli software vib install -v /tmp/smartctl-6.6-4321.x86_64.vib

The tool is located at /opt/smartmontools/smartctl and works just like the Linux version.
Locate physical disks with ls -l /dev/disks/

/opt/smartmontools/smartctl -d [Device Type] —all /dev/disks/[DISK]

# smartctl -d sat —all /dev/disks/t10.ATA_____Samsung_SSD_850_EVO_M.2_250GB___________S24BNXAG805065D_____
smartctl 6.6 2016-05-10 r4321 [x86_64-linux-6.0.0] (daily-20160510)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Samsung based SSDs
Device Model:     Samsung SSD 850 EVO M.2 250GB
Serial Number:    S24BNXAG805065D
LU WWN Device Id: 5 002538 d404b9f9f
Firmware Version: EMT21B6Q
User Capacity:    250,059,350,016 bytes [250 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
SMART support is: Available — device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART Status not supported: Incomplete response, ATA output registers missing
SMART overall-health self-assessment test result: PASSED
Warning: This result is based on an Attribute check.

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
Total time to complete Offline
data collection:                (    0) seconds.
Offline data collection
capabilities:                    (0x53) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        No Offline surface scan supported.
                                        Self-test supported.
                                        No Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 133) minutes.
SCT capabilities:              (0x003d) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       —       0
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       —       5040
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       —       35
177 Wear_Leveling_Count     0x0013   094   094   000    Pre-fail  Always       —       122
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       —       0
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       —       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       —       0
183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       —       0
187 Uncorrectable_Error_Cnt 0x0032   100   100   000    Old_age   Always       —       0
190 Airflow_Temperature_Cel 0x0032   049   034   000    Old_age   Always       —       51
195 ECC_Error_Rate          0x001a   200   200   000    Old_age   Always       —       0
199 CRC_Error_Count         0x003e   100   100   000    Old_age   Always       —       0
235 POR_Recovery_Count      0x0012   099   099   000    Old_age   Always       —       26
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       —       6345601655

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

Warning! SMART Selective Self-Test Log Structure error: invalid SMART checksum.
SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
  255        0    65535  Read_scanning was never started
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.