VO
HGST Travelstar™ Z7K500.B --- под максимальный размер очереди отведено 5 бит. итого 32
Size: a a a
2020 May 31
VO
Да вот как раз на последовательном вводе/выводе он особо и не нужен, он рандом именно и улучшает
как раз последовательный. что бы 10 команд на чтение подряд лежащих блоков выполнилось за один оборот диска, а не тормозилось каждый раз ожиданием из-за того что сектор из-под головки улетел пока хост с ответом разбирался
IF
глубина не важна, ну а в реальности у нас и будет рандом.
глубина всегда влияет и особенно при рандоме. Чем больше глубина, тем выше итоговый latency на hdd.
IF
HGST Travelstar™ Z7K500.B --- под максимальный размер очереди отведено 5 бит. итого 32
это же вроде обычный десктоп hdd?
VO
ну мыже говорим о том, как получить меньше 14мс?
VO
первый поавшийся мануал на hgst
VO
могу другой взять
IF
ну мыже говорим о том, как получить меньше 14мс?
когда мы об этом говорили? :)
AT
HGST Travelstar™ Z7K500.B --- под максимальный размер очереди отведено 5 бит. итого 32
HUS726040ALS210
254 очередь
254 очередь
AT
как раз последовательный. что бы 10 команд на чтение подряд лежащих блоков выполнилось за один оборот диска, а не тормозилось каждый раз ожиданием из-за того что сектор из-под головки улетел пока хост с ответом разбирался
Рандомная статья тоже говорит что всё таки для рандомного
http://sqlcom.ru/dba-tools/manage-disk-queue/
http://sqlcom.ru/dba-tools/manage-disk-queue/
VO
HUS726040ALS210
254 очередь
254 очередь
а в спеке написанно 128...
да, у SASов больше
да, у SASов больше
VO
когда мы об этом говорили? :)
когда кто-то утверждал что на hdd может быть latency 1ms и меньше
IF
когда кто-то утверждал что на hdd может быть latency 1ms и меньше
1. нет типа трафика, последовательно пжст, будет работать readahead.
2. про меньше 1 мс тоже речи не было
2. про меньше 1 мс тоже речи не было
L
подскажите плиз почему так
ceph-volume lvm zap /dev/sdd --destroy
--> Zapping: /dev/sdd
stderr: wipefs: error: /dev/sdd: probing initialization failed: Device or resource busy
--> failed to wipefs device, will try again to workaround probable race condition
stderr: wipefs: error: /dev/sdd: probing initialization failed: Device or resource busy
--> failed to wipefs device, will try again to workaround probable race condition
/dev/sdd не подмонтирован, его только подкинули в систему
ceph-volume lvm zap /dev/sdd --destroy
--> Zapping: /dev/sdd
stderr: wipefs: error: /dev/sdd: probing initialization failed: Device or resource busy
--> failed to wipefs device, will try again to workaround probable race condition
stderr: wipefs: error: /dev/sdd: probing initialization failed: Device or resource busy
--> failed to wipefs device, will try again to workaround probable race condition
/dev/sdd не подмонтирован, его только подкинули в систему
L
и что можно сделать с этим
IF
LS
подскажите плиз почему так
ceph-volume lvm zap /dev/sdd --destroy
--> Zapping: /dev/sdd
stderr: wipefs: error: /dev/sdd: probing initialization failed: Device or resource busy
--> failed to wipefs device, will try again to workaround probable race condition
stderr: wipefs: error: /dev/sdd: probing initialization failed: Device or resource busy
--> failed to wipefs device, will try again to workaround probable race condition
/dev/sdd не подмонтирован, его только подкинули в систему
ceph-volume lvm zap /dev/sdd --destroy
--> Zapping: /dev/sdd
stderr: wipefs: error: /dev/sdd: probing initialization failed: Device or resource busy
--> failed to wipefs device, will try again to workaround probable race condition
stderr: wipefs: error: /dev/sdd: probing initialization failed: Device or resource busy
--> failed to wipefs device, will try again to workaround probable race condition
/dev/sdd не подмонтирован, его только подкинули в систему
Device or resource busy
IF
чудес все таки не бывает, значит кто-то использует. Например lvm
L
как понять что лвм?
AK
Если это SSD - blkdiscard /dev/sdd, если HDD - dd if=/dev/zero of=/dev/sdd bs=1024k count=10
VO
Рандомная статья тоже говорит что всё таки для рандомного
http://sqlcom.ru/dba-tools/manage-disk-queue/
http://sqlcom.ru/dba-tools/manage-disk-queue/
в данной статье говорится (не знаю откуда, мне цифры кажутся завышенными, к примеру я не видел даташитов на 3.5" диски у которых seek time был бы 3.4ms хотя специально искал.) что растут IOPSы суммарные но ценой роста задержки.