Linux VPS میں ڈسک واقعی NVMe ہے؟ تصدیق کریں

Linux پر NVMe ڈسک کی 4 مراحل میں تصدیق کریں

Linux VPS پر NVMe ڈسک کی تصدیق کے لیے یہ 4 checks اسی ترتیب سے چلائیں: device name معلوم کرنے کے لیے lsblk، spinning media کی شناخت کے لیے sysfs میں rotational flag، حقیقی NVMe controller کی تصدیق کے لیے nvme list، اور مختصر fio run، کیونکہ ایک host صرف اسی ایک number کو بدل نہیں سکتا۔ پہلے 3 checks میں ہر ایک کو 1 second لگتا ہے۔ آخری check فیصلہ واضح کر دیتا ہے، کیونکہ زیادہ تر VPS platforms پر hypervisor physical disk کو guest سے چھپا دیتا ہے۔

NVMe (non-volatile memory express) وہ protocol ہے جس کے ذریعے flash storage PCIe (peripheral component interconnect express) lanes پر رابطہ کرتی ہے۔ اس نے SATA اور AHCI path کی جگہ لی، جو spinning drives کے لیے بنایا گیا تھا۔ یہ تیز ہے کیونکہ CPU اور flash کے درمیان queueing bottleneck ختم ہو جاتا ہے۔ Virtual machine کے اندر آپ عموماً اس protocol سے براہِ راست رابطہ نہیں کرتے۔ آپ اس virtual disk سے رابطہ کرتے ہیں جسے host آپ کے لیے assemble کرتا ہے۔ اس لیے guest میں device name rack میں موجود media کے بجائے driver کی وضاحت کرتا ہے۔

مرحلہ 1: lsblk کیا دکھاتا ہے؟

lsblk کرنل کی block devices کی فہرست پڑھتا ہے۔ -d flag partitions چھپا دیتا ہے، اس لیے ہر disk کے لیے ایک سطر دکھائی دیتی ہے۔

lsblk -d -o NAME,ROTA,SIZE,TYPE,TRAN,MODEL

KVM VPS عموماً اس طرح جواب دیتا ہے:

NAME ROTA  SIZE TYPE TRAN MODEL
vda     0   80G disk

تین naming patterns تقریباً ہر Linux server کا احاطہ کرتے ہیں:

• nvme0n1 NVMe controller 0 پر namespace 1 ہے۔ آپ کا guest ایک حقیقی یا emulated NVMe device استعمال کر رہا ہے۔
• sda SCSI layer ہے۔ حقیقی SATA اور SAS disks یہاں ظاہر ہوتی ہیں، اور virtio-scsi driver بھی اسی layer کو استعمال کرتا ہے۔
• vda virtio-blk ہے، جو paravirtual block driver ہے اور زیادہ تر KVM hosts اسے default طور پر استعمال کرتے ہیں۔

TRAN (transport) column، NVMe device کے لیے nvme اور ایسی SATA disk کے لیے sata دکھاتا ہے جسے guest براہ راست دیکھ سکتا ہے۔ virtio-blk کے تحت یہ عموماً خالی ہوتا ہے، کیونکہ guest کے لیے report کرنے کو کوئی physical transport موجود نہیں ہوتا۔ اسی وجہ سے MODEL بھی خالی ہوتا ہے۔ VPS پر خالی model string معمول کی بات ہے اور اس سے hardware کے بارے میں کوئی معلومات نہیں ملتیں۔

مرحلہ 2: spinning disk کو خارج کریں

DISK=$(lsblk -dno NAME,TYPE | awk '$2 == "disk" { print $1; exit }')
echo "checking $DISK"
cat "/sys/block/$DISK/queue/rotational"
readlink -f "/sys/block/$DISK"

rotational فائل میں 1 درج ہوتا ہے جب kernel کے خیال میں device میں spinning platters موجود ہوں، اور باقی تمام devices کے لیے 0 درج ہوتا ہے۔ bare metal پر یہ value drive سے آتی ہے۔ virtio-blk کے تحت یہ host کے مقرر کردہ feature bit سے آتی ہے، اس لیے 0 ایک عام hard drive کے امکان کو خارج کرتا ہے، مگر اس سے آگے کچھ ثابت نہیں ہوتا۔ پھر بھی اسے پڑھیں: solid state storage کے طور پر فروخت کیے گئے plan میں 1 صاف تضاد ہے، اور یہ وہ واحد screenshot ہے جس سے support اختلاف نہیں کر سکتی۔

readlink -f sysfs symlink کو resolve کرتا ہے اور وہ bus دکھاتا ہے جس سے device منسلک ہے:

/sys/devices/pci0000:00/0000:00:05.0/virtio2/block/vda

اس path میں virtio کا لفظ اس مرحلے کا جواب ہے۔ NVMe device کا path nvme پر مشتمل ہوتا ہے، مثلاً /sys/devices/pci0000:00/0000:01:00.0/nvme/nvme0/nvme0n1، جبکہ براہِ راست منسلک ATA disk کے path میں ata1 شامل ہوتا ہے۔ یہ وہی حقیقت ہے جو lsblk نے دکھائی تھی، مگر اسے formatted column کے بجائے kernel سے حاصل کیا گیا ہے۔ یہ اس وقت مفید ہوتا ہے جب TRAN field خالی ہو۔

مرحلہ 3: nvme-cli اور PCI bus سے معلومات لیں

sudo apt update
sudo apt install -y nvme-cli pciutils
sudo nvme list || echo "nvme-cli found no NVMe device"
lspci | grep -i -e nvme -e 'non-volatile' || echo "no NVMe controller on this guest's PCI bus"

nvme list ہر namespace کے لیے ایک row دکھاتا ہے۔ اس میں controller کا serial number، model string اور firmware revision شامل ہوتے ہیں۔ خالی table کا مطلب ہے کہ آپ کے guest کو کوئی NVMe device فراہم نہیں کی گئی۔ lspci کا کوئی matching line نہ دکھانا بھی یہی بات دوسرے زاویے سے ثابت کرتا ہے: آپ کے guest کو نظر آنے والی virtual PCI bus پر کوئی NVMe controller موجود نہیں۔ virtio VPS پر دونوں نتائج کا خالی آنا معمول ہے۔ ان میں سے کوئی بھی نتیجہ اس بات کا ثبوت نہیں کہ host پر NVMe drives موجود نہیں ہیں۔

اگر کوئی namespace ظاہر ہو تو nvme-cli مزید معلومات فراہم کرتا ہے۔ sudo nvme id-ctrl /dev/nvme0 controller identity دکھاتا ہے، جبکہ sudo nvme smart-log /dev/nvme0n1 temperature، power-on hours اور rated write endurance کے استعمال شدہ percentage کو دکھاتا ہے۔ یہ commands صرف اس وقت چلائیں جب nvme list نے واقعی کوئی device درج کی ہو، کیونکہ دونوں commands کو کھولنے کے لیے ایک حقیقی /dev/nvme* node درکار ہوتا ہے۔

واقعی NVMe host پر بھی /dev/vda کیوں دکھائی دیتا ہے

Hypervisor یہ طے کرتا ہے کہ guest کو device model کون سا دکھائی دے گا، اور یہ انتخاب بنیادی storage media سے آزاد ہوتا ہے۔ عام طور پر 3 انتظامات دیکھنے میں آتے ہیں۔

• کسی file، logical volume یا ZFS dataset پر چلنے والا virtio-blk یا virtio-scsi، جہاں بنیادی storage NVMe drives ہوں۔ آپ کو vda یا sda دکھائی دیتا ہے۔ Storage NVMe ہے، لیکن guest کے پاس یہ جاننے کا کوئی طریقہ نہیں ہوتا۔
• کسی بھی storage کے سامنے emulated NVMe controller۔ ایسی صورت میں nvme0n1 دکھائی دیتا ہے، چاہے bytes SATA array پر محفوظ ہوں یا دو racks دور موجود network volume پر۔
• PCIe passthrough، جس میں host ایک physical controller کسی ایک guest کے حوالے کر دیتا ہے۔ آپ کو حقیقی nvme0n1 اور حقیقی model string دکھائی دیتی ہے۔ Shared VPS plans میں یہ کم ہوتا ہے، کیونکہ card پھر صرف اسی ایک customer کے لیے dedicated رہتا ہے۔

اس لیے device name دونوں سمتوں میں آپ کو گمراہ کر سکتا ہے۔ مزید یہ کہ host آپ کی writes اور flash کے درمیان write-back cache، RAID layer یا replicated network volume رکھ سکتا ہے۔ ان میں سے ہر چیز /sys میں ایک بھی نام تبدیل کیے بغیر حاصل ہونے والی performance بدل دیتی ہے۔ اسی لیے device name سے جانچ شروع کریں، لیکن اسی پر نہ رکیں۔ اگر آپ ابھی plan منتخب کر رہے ہیں تو NVMe اور SATA SSD storage کے درمیان فرق سے معلوم ہوتا ہے کہ ہر tier کے لیے ادائیگی کرنا حقیقتاً کب مفید ہے۔

اصل ٹیسٹ latency ہے، اس لیے اسے ناپیں

fio (flexible I/O tester) حقیقی فائل کے خلاف حقیقی reads چلاتا ہے اور بتاتا ہے کہ ہر read مکمل ہونے میں کتنا وقت لگا۔ یہاں چھوٹے random reads درست workload ہیں، کیونکہ یہ media تک round trip کو ظاہر کرتے ہیں اور read-ahead کے ذریعے پورے نہیں کیے جا سکتے۔

پہلے test file بنائیں اور تصدیق کریں کہ یہ filesystem unbuffered I/O قبول کرتا ہے۔ --direct=1 فائل کو O_DIRECT کے ساتھ کھولتا ہے، جو page cache کو bypass کرتا ہے۔ اس کے بغیر آپ اپنی RAM کی پیمائش کریں گے اور ایسے اعداد حاصل ہوں گے جو کوئی disk فراہم نہیں کر سکتی۔

sudo apt install -y fio
fio --name=prep --filename=/var/tmp/nvme-check.tmp --size=256M --bs=1M --rw=write --direct=1 --end_fsync=1 > /dev/null \
  && echo "unbuffered writes work here, the timing test is valid" \
  || echo "this filesystem refuses direct=1, so the timing test below will not run"

اگر اس نے refusal message دکھایا تو منتخب کیا گیا path ایسے filesystem پر ہے جس میں O_DIRECT support موجود نہیں۔ Container overlay filesystems اور کچھ network filesystems اسی طرح کام کرتے ہیں۔ VPS کے root filesystem پر موجود کسی directory کا انتخاب کریں اور دوبارہ کوشش کریں۔ اگر اس نے success دکھایا تو measurement چلائیں:

fio --name=randread4k --filename=/var/tmp/nvme-check.tmp --bs=4k --rw=randread \
  --direct=1 --iodepth=1 --numjobs=1 --runtime=20 --time_based --group_reporting \
  || echo "fio stopped early, read its first line for the reason"
rm -f /var/tmp/nvme-check.tmp

یہ run جان بوجھ کر محدود رکھا گیا ہے: ایک job، queue depth 1، بیس سیکنڈ، اور 256 MB data۔ اس سے disk بھرے گی نہیں اور abuse کی وجہ سے آپ flag نہیں ہوں گے۔ اس سوال کے لیے queue depth 1 ہی درست setting ہے، کیونکہ deep queues parallelism کے ذریعے سست device کی تاخیر چھپا دیتی ہیں، جبکہ latency زیادہ رہتی ہے۔

fio کے آؤٹ پٹ کو پڑھنا

دو سطریں اہم ہیں۔ خلاصہ سطر read: IOPS=9012, BW=35.2MiB/s جیسی نظر آتی ہے، اور اس کے نیچے fio ایک clat بلاک دکھاتا ہے۔ clat تکمیل کی تاخیر ہے: fio کے read جمع کرانے اور kernel کے data واپس کرنے کے درمیان کا وقت۔ clat percentiles فہرست میں avg کی قدر پڑھیں، پھر 99.00th percentile پڑھیں۔ اوسط آپ کو storage class بتاتی ہے۔ 99th percentile بتاتا ہے کہ اسی host پر موجود کوئی دوسرا صارف آپ کو کتنی بار انتظار کرواتا ہے۔

fio تاخیر کو کم قدروں کی صورت میں microseconds میں دکھاتا ہے اور قدریں زیادہ ہونے پر milliseconds میں تبدیل ہو جاتا ہے۔ کسی بھی موازنے سے پہلے سطر میں دی گئی unit دیکھیں۔

کون سے اعداد NVMe کلاس کو SATA کلاس سے الگ کرتے ہیں

ذیل کے اعداد queue depth 1 پر single-job 4k random reads کے لیے عام طور پر شائع شدہ اقدار ہیں۔ یہ اعداد August 2026 تک vendor documentation اور community benchmarks سے جمع کیے گئے ہیں۔ یہ موازنے کے لیے bands ہیں، آپ کے سرور کی پیمائش نہیں۔

[
  {
    "label": "Local NVMe",
    "avg_latency_us": 110
  },
  {
    "label": "Local SATA SSD",
    "avg_latency_us": 320
  },
  {
    "label": "Network block storage",
    "avg_latency_us": 900
  }
]

[
  {
    "label": "Local NVMe",
    "iops": "9,000"
  },
  {
    "label": "Local SATA SSD",
    "iops": "3,100"
  },
  {
    "label": "Network block storage",
    "iops": "1,100"
  }
]

ایک local NVMe volume ایک 4k random read کا جواب تقریباً 110 microseconds میں دیتا ہے اور queue depth 1 پر تقریباً 9,000 IOPS تک پہنچتا ہے۔ ایک local SATA SSD تقریباً 320 microseconds اور 3,100 IOPS کے قریب رہتا ہے۔ Network attached block storage تقریباً 900 microseconds اور 1,100 IOPS تک پہنچتا ہے، کیونکہ flash تک رسائی سے پہلے ہر read کو network hop سے گزرنا پڑتا ہے۔

queue depth 1 پر یہ دونوں columns ایک ہی حقیقت کو دو مرتبہ بیان کرتے ہیں: ایک وقت میں ایک read ہونے کی صورت میں throughput، latency کے الٹ کے برابر ہوتا ہے۔ اگر آپ کی average 110 کے قریب ہو، نہ کہ 320 microseconds کے، تو آپ NVMe کلاس storage استعمال کر رہے ہیں، چاہے lsblk نے device کو کوئی بھی نام دیا ہو۔ اگر یہ 900 microseconds کے قریب ہو، تو path میں local flash سے زیادہ سست کوئی چیز موجود ہے، اور order page پر NVMe کا لفظ آپ کے volume کے بجائے host کی drives کو بیان کر رہا ہے۔

شکایت کرنے سے پہلے اسے ایک سے زیادہ بار چلائیں

ایک بار چلانا صرف ایک نمونہ ہے، حتمی نتیجہ نہیں۔ VPS اپنی disks دوسروں کے ساتھ share کرتا ہے، اس لیے کوئی مصروف پڑوسی آپ کی latency کو دس منٹ کے لیے دوگنا کر سکتا ہے اور پھر یہ مسئلہ ختم ہو سکتا ہے۔ بعض platforms burst credits بھی دیتے ہیں، جس سے کسی بھی test کے ابتدائی منٹ غیر معمولی طور پر اچھے دکھائی دیتے ہیں۔ اسی command کو دن کے مختلف اوقات میں تین یا چار بار چلائیں اور بہترین نہیں بلکہ بدترین نتیجے کا موازنہ کریں۔ ایک خراب run محض عارضی صورتِ حال ہو سکتی ہے۔ لیکن اگر یہی pattern بار بار نظر آئے تو یہ support ticket درج کرنے کے قابل fault ہے، اور تین time-stamped fio outputs کے ساتھ ticket زیادہ مؤثر ثابت ہوتا ہے۔ CPU اور network کے ساتھ disk کا بھی وسیع جائزہ لینے کے لیے مکمل VPS benchmark run دیگر subsystems پر بھی یہی طریقۂ کار استعمال کرتا ہے۔

جواب کے ساتھ کیا کرنا ہے

اگر latency NVMe band میں ہے تو device name کی فکر چھوڑ کر آگے بڑھیں۔ vda کوئی downgrade نہیں ہے۔ یہ زیادہ تر hosts کے پیش کردہ virtual disk drivers میں سب سے تیز ہے، اور آپ کو یہی چاہیے۔

اگر local NVMe کے طور پر فروخت کیے گئے plan پر latency network storage band میں ہے تو آپ کے پاس ایک مخصوص اور قابلِ تکرار دعویٰ موجود ہے: مکمل fio command، اوسط completion latency، اور وہ اوقات جب آپ نے test چلایا۔ یہ forum argument کے بجائے support ticket کا معاملہ ہے۔ بھیجنے سے پہلے تصدیق کریں کہ disk صرف full یا شدید fragmented نہیں ہے، اور یہ بھی یقینی بنائیں کہ test کے دوران box پر کوئی process بہت زیادہ write نہیں کر رہا۔

یہ check اسی دن چلائیں جس دن آپ provision کریں، نہ کہ اس دن جب کوئی چیز slow محسوس ہو، تاکہ بعد میں موازنہ کرنے کے لیے baseline موجود ہو۔ یہ نئے VPS پر پہلے دس منٹ کے کاموں میں firewall اور SSH keys configure کرنے کے ساتھ فطری طور پر شامل ہو جاتا ہے۔ اگر storage tiers کے درمیان پورا فرق اب بھی واضح نہیں ہے تو SSD VPS آپ کو حقیقت میں کیا فراہم کرتا ہے اس کے بنیادی نکات بیان کرتا ہے۔

FAQ

lsblk میرے host کی NVMe کی تشہیر کے باوجود /dev/vda کیوں دکھاتا ہے؟

کیونکہ vda آپ کے guest میں virtio-blk driver کا نام بتاتا ہے، host کے hardware کا نہیں۔ KVM hypervisor ایک paravirtual block device فراہم کرتا ہے، جس کے پیچھے کوئی file، logical volume یا dataset ہو سکتا ہے۔ یہ backing store NVMe drives پر موجود ہو سکتا ہے، جبکہ guest کو اس کا کبھی علم نہیں ہوتا۔ یہ نام virtualisation layer کی وضاحت کرتا ہے۔ صرف latency measurement ہی storage media کی وضاحت کرتی ہے۔

کیا rotational 0 سے یہ ثابت ہوتا ہے کہ میرے پاس NVMe disk ہے؟

نہیں۔ /sys/block/<dev>/queue/rotational کا 0 پر مشتمل ہونا بتاتا ہے کہ kernel کے خیال میں اس device میں spinning platters نہیں ہیں۔ virtio کے تحت یہ value host کے منتخب کردہ feature bit سے set ہوتی ہے۔ اس سے عام hard drive خارج ہو جاتی ہے۔ لیکن یہ NVMe اور SATA SSD میں فرق نہیں بتا سکتی، اور نہ ہی local flash اور network volume میں۔ اگر 1 موجود ہو تو اس پر کارروائی کرنا پھر بھی مفید ہے، کیونکہ یہ solid state storage کے طور پر فروخت کیے گئے کسی بھی منصوبے کے دعوے سے متصادم ہے۔

میرے VPS پر nvme list خالی کیوں ہے؟

کیونکہ آپ کے guest کو کوئی NVMe controller فراہم نہیں کیا گیا۔ nvme list اور lspci دونوں وہی devices پڑھتے ہیں جو virtual machine کو دکھائی دیتی ہیں، اور virtio-blk یا virtio-scsi disk enumerate کرنے کے لیے کوئی NVMe controller پیش نہیں کرتی۔ زیادہ تر VPS plans پر خالی table معمول کی بات ہے۔ اس سے یہ ثابت نہیں ہوتا کہ host میں NVMe drives موجود نہیں ہیں۔ sudo apt install -y nvme-cli کے ذریعے nvme-cli install کریں، اور خالی table کی توقع رکھیں، جب تک کوئی controller pass through نہ کیا گیا ہو۔

کون سا fio نتیجہ NVMe class storage شمار ہوتا ہے؟

queue depth 1 پر، 4k random reads اور --direct=1 کے ساتھ، تقریباً 110 microseconds کی average completion latency NVMe class storage کی نشاندہی کرتی ہے، اور اس سے تقریباً 9,000 IOPS حاصل ہوتے ہیں۔ تقریباً 320 microseconds SATA SSD کی طرف اشارہ کرتے ہیں، جبکہ تقریباً 900 microseconds network attached storage کی طرف اشارہ کرتے ہیں، جہاں ہر read network hop سے گزرتی ہے۔ یہ August 2026 کے عام published bands ہیں، اس لیے exact figures کے بجائے orders of magnitude کا موازنہ کریں۔ نتیجہ اخذ کرنے سے پہلے مختلف اوقات میں run دوبارہ کریں۔