Jelenleg eleg sokat szenvedunk az un. advanced format diszkekkel...
Ma reggel osszehasonlitaskepp kiszurtam egy furcsa hibat:
[root@fedorappc64 ~]# fdisk -l /dev/sds
Disk /dev/sds: 1 GiB, 1073741824 bytes, 2097152 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 65536 bytes
Szoval az fdisk azt mondja nekem, hogy a fizikai blokkmeret 4k...
Ez kicsit gyanus. Ugyanez a LUN atmappelve egy AIX hostra (7.1 TL3 SP1) a kovetkezot hazudja magarol :
# echo "scsidisk hdisk31" | kdb | grep block_size
uint cfg_block_size = 0x200;
uint block_size = 0x200;
Szoval az AIX csak 512 byte szektormeretunek latja ugyanazt a LUN-t.
Terjunk vissza a Linux-hoz.
Minden diszk informacio elerheto a /sys alatt is.
Esetunkben:
[root@fedorappc64 ~]# cat /sys/class/block/sdr/queue/physical_block_size
4096
[root@fedorappc64 ~]# cat /sys/class/block/sdr/queue/logical_block_size
512
Tehat a kernel szerint is a fizikai blokkmeret es a logikai blokkmeret megegyezik az fdisk altal reportaltal. Gondolom az fdisk innet veszi ezeket az informaciokat. (Nem volt meg idom vegigmenni az fdisk logikajan)
A harmadik lehetosegunk linuxon az sg3_utils csomag altal szallitott sginfo utility.
Itt nekunk az "Format Device mode page (0x3)" informaciora van szuksegunk ami igy nez ki erre a diszkre:
[root@fedorappc64 ~]# sginfo -f /dev/sds
Format Device mode page (0x3)
-----------------------------
Tracks per Zone 0
Alternate sectors per zone 0
Alternate tracks per zone 0
Alternate tracks per lu 0
Sectors per track 128
Data bytes per physical sector 512
Interleave 0
Track skew factor 0
Cylinder skew factor 0
Supports Soft Sectoring 1
Supports Hard Sectoring 1
Removable Medium 0
Surface 0
Linux eseten kinek lehet hinni?
A kernelnek ?
Az SG Informacionak ?
Az AIX altal mutatott blokkmeretnek ?
Lehetseges, hogy ez egy bug a Linux/AIX/NetApp SAN-ban ...
Viszont az sginfo es az AIX informacio szepen egybevag. Szoval arra hajlok, hogy az igazsag az 512 byte mint blokkmeret.
- 2943 megtekintés
Hozzászólások
Szerintem 4 kiB a fizikai méret, csak kompatibilitási okokból behazudja a 0.5 kiB-ot is. Majdnem biztos vagyok benne, hogy az a program, amelyik csak 512 byte-ot ad vissza, elég öreg, s egy kompatibilitási rétegen keresztül érdeklődik a valóságról. Nagyjából, mint az ifconfig vs. ip parancsok.
Valódi 512 byte-os szektorral rendelkező disk esetén ilyesmi a válasz:
fdisk -l /dev/sda
Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Szerk.: persze a disk az ATA felületen tud 512 byte-os szektorokkal működni, tehát lényegében már a block eszköz firmware-e emulálja ezt, csak lassú lesz. Nyilván azért, mert amikor egy szektort kiírsz, el kell hoznia 4 kB-ot, a megfelelő 512 byte-ot módosítania kell, majd vissza kell írnia. Nem a kernelnek, hanem a disk kontrollerének. De valószínűleg ő is megoldja cache-ben, de akkor is. Ha van módod, 4 kiB-osként kezeld szerintem.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Megneztem egy par tarolot...
SSD, nem hinnem, hogy 512 byte-os lenne:
Disk /dev/sdb: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Egy masik SSD:
Disk /dev/sdc: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Regebbi HDD:
Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Egy VPS, SSD:
Disk /dev/sda: 98.8 GB, 98788442112 bytes, 192946176 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Pillanatnyilag ennyihez ferek hozza... Lehet, hogy az SSD-k 512-t hazudnak physical-nak?
Szoval szerintem egyiknek se lehet hinni... :)
- A hozzászóláshoz be kell jelentkezni
SSD-nél mi szól a 4 kiB-os blokkméret mellett? Az egész úgy indult, hogy a HDD-n feszegetni kezdik a fizikailag még biztonságosan tárolható adatsűrűséget. Az 512 byte-os szektorok esetében túl nagy az overhead a bevezető gap-ek és a CRC miatt. Mivel ezen szinkron szakasz szektoronként kell, kitalálták, hogy legyen nagyobb szektorméret, így kevesebb lesz a szektorok száma, s a HDD-n az összes gap és CRC is kevesebb. Mondhatnám, javították a (hasznos adat)/(összes adat) arányt, tehát kisebb lett az overhead, s így ugyanakkora adatsűrűség és felület mellett több hasznos adat fér a lemezre.
Mivel SSD-nél nincsenek gap-ek - mondjuk CRC még lehet, bár az szerintem nem olyan sok arányaiban -, így hiába korszerű, nem igazán látom a nagy szektorméret előnyét.
Az a régebbi HDD meg szerintem nem annyira régi, legalább is gondolom, 10 évnél nem öregebb. Abban viszont igazad van, hogy a kernel csak abból tud kiindulni, amit az eszköz mond magáról. Akárhogyan kezeli belül a kontroller az SSD-t - például a nagyobb élettartam miatt állandóan relokálja a szektorokat, amelyeket kifelé ugyanazon LBA címűnek mutat -, az ATA felületen mond magáról valamit, a kernel pedig elhiszi, nem is tehet mást.
Éppen ezért lényegében biztos vagyok abban, hogy a kérdező által említett HDD 4 kiB-os szektorokkal rendelkezik. Ezt azért nem fedi el tökéletesen a HDD kontrollere, mert ha a kernel igazodik a natív tárolási módhoz, nyilván gyorsabb lesz a block device elérése.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Hm, tenyleg ezert vezettek be a 4K blokmeretet... Ugy emlekeztem, hogy a sebessegnel segitett a nagyobb blokmeret, es a filerendszerek is 512-nel nagyobb blokkokat hasznalnak alapbol (NTFS pl default 4k-t), ugyhogy nem erdemes kisebbeket cimezgetni. S ugy emlekeztem, hogy az SSD-knek alapbol meg nagyobb, pl a torlest egyes SSD-k 1M-es adagokban vegzik. Ma is tanultunk valamit. :)
A regebbi HDD-m 2011-es model, de ugy tunik, hogy meg most is lehet kapni... Erdekes, azt hittem, hogy kicsit surubben vonjak ki a forgalombol a regebbi modeleket. :)
Ugy olvastam, hogy HDD-ket 2011-tol 4k-s blokmerettel gyartjak (http://www.seagate.com/gb/en/tech-insights/advanced-format-4k-sector-hard-drives-master-ti/), ugyhogy ha nem regebbi model a kerdezo HDD-je, akkor valoszinuleg 4k-s.
- A hozzászóláshoz be kell jelentkezni
Filerendszernél azért is szokás több szektoros cluster-eket használni, mert kis cluster méret esetén nagyon sok foglalási egységet kell nyilvántartani, ami nagyon nagy filerendszer leírót eredményez. Pl. egy 500 GB-os filerendszer esetén 512 byte-os foglalási egységből van 1 milliárd. Ha 32 biten tároljuk a leíróban a láncolt lista pointereit - a 32 bit ebben az esetben közel van a határhoz -, akkor csak a leíró 4 GB. Eszméletlen szívás, mert ráadásul jó volna RAM-ban tartani annak érdekében, hogy a file műveletek gyorsak legyenek. Na, de 4 GB-ot csak erre RAM-ban?
Persze, ha meg a foglalási egység nagy, akkor elég pazarlóan tárolódnak a kis file-ok.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
"As of 2014, most SSDs use NAND-based flash memory, "
https://en.wikipedia.org/wiki/Flash_memory#NAND_memories
NAND szeru rendezodest lehet feltelezni,
4k tol valamivel nagyobb `sector` merettel,
es csak nagyobb csoportban valo torolhetoseget.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Jogos, de 4 kiB-nél nagyobbat akkor sem szerencsés az oprendszer felé mondania, mert akkor a legkisebb kezelhető egység ilyen nagy lesz, ezzel viszonylag magas alsó korlátot adva a filerendszer cluster méretének, ami nagyon hatékonytalan tárolást idéz elő kis file-oknál. Gondolom, itt az SSD firmware-e trükközik, hogy noha egyben kezel egy blokkot belül, kifelé azt sok szektorként mutatja meg.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Ami meg a tortenethez tartozik, hogy a NetApp ext mondja a LUN-rol:
Cluster::lun*> show -v -vserver Dev -path /vol/sysrestest/lun2
Vserver Name: Dev
LUN Path: /vol/sysrestest/lun2
Volume Name: sysrestest
Qtree Name: ""
LUN Name: lun2
LUN Size: 1GB
Prefix Size: 0
OS Type: aix
Space Reservation: enabled
Serial Number: 7S7Ah$GTRvHn
Comment:
Space Reservations Honored: true
Space Allocation: disabled
State: online
LUN UUID: 9b44042e-2968-4772-b6fe-6a42640986c4
Mapped: mapped
Block Size: 512
Device Legacy ID: -
Device Binary ID: -
Device Text ID: -
Read Only: false
Inaccessible Due to Restore: false
Used Size: 48KB
Maximum Resize Size: 64.00GB
Creation Time: 2/19/2016 10:17:09
Class: regular
Clone: false
Clone Autodelete Enabled: false
QoS Policy Group: -
Ha egy kicsit tovabb megyek az SCSI parancsok fele akkor a kovetkezot latom:
Amikor az sginfo fut kozvetlen IOCTL-t kuld a kerdeses device fele es dekodolja a valaszul kapott CDB valaszt.
Nem hasznal semmilyen mas informacios technikat a /sys and/or /proc alol, hogy azt adja valaszul.
Igazabol a kernel/fdisk-en kivul kb minden mas (AIX, sginfo, SAN) azt mondja, hogy a device 512 byte blokkmerettel rendelkezik...
Visszaterve az fdisk-re:
open("/dev/sdr", O_RDONLY|O_CLOEXEC) = 3
...
ioctl(3, CDROM_GET_CAPABILITY, 0) = -1 EINVAL (Invalid argument)
ioctl(3, BLKALIGNOFF, 0) = 0
ioctl(3, BLKIOMIN, 4096) = 0
ioctl(3, BLKIOOPT, 65536) = 0
ioctl(3, BLKPBSZGET, 4096) = 0
ioctl(3, BLKSSZGET, 512) = 0
ioctl(3, BLKSSZGET, 512) = 0
...
A dokumentacio szerint a BLKPBSZGET IOCTL a fizikai blokkmeretet adja meg ...
Ugy erzem ez meg nem teljesen lefutott kor ...
- A hozzászóláshoz be kell jelentkezni
Az a bajom, hogy a többinél sem látom, hogy 1-et adott volna vissza.
Vannak ilyenek:
/sys/block/sda/queue/hw_sector_size
/sys/block/sda/queue/physical_block_size
/sys/block/sda/queue/logical_block_size
Az sda értelemszerűen.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Helyes az ami oda van irva, fizikai blokk meret 4096 elvileg ezeknel de felfele a linuxnak mar 8 x 512 blokkot mutat a diszk firmware. Az AIX is ezert mutat ennyit tippre, az hogy a diszk firmware ezt mar mashogy irja majd le aktualisan a lemezekre felfele nem latszik. Gondolom tortenelmi okokbol csinaltak meg hogy kompatibilis legyen. En a kernelre szavazok, o igazat mondd, eggyel fentebbi retegen az fdisk vagy az sg utililyt mar azt latja amit latnia kell.
- A hozzászóláshoz be kell jelentkezni
Én is így látom, különben a kernel honnan venné azt a 4 k-t. Mondjuk az egy következő kérdés, hogy ki lehet-e használni a 4 k-s blokkméret előnyeit. Ha az interface felületen van erre külön lehetőség, akkor nem is kérdés. Ha viszont csak 0.5 k-s blokkokat mutat az eszköz, akkor is lehet szerintám a kernel által 4 k-nként kezelni, mert így 8 * 0.5 k-s burst-ökben megy az adat, aminek megvan az a szépsége, hogy az eszköz buffere mindig épp megtelik a fizikai kiírás előtt, a firmware-nek nem lesz dolga azzal, hogy a disk-ről és az interface-ről jövő adatokat összefésülve írja vissza a disk-re. Egy dologra kell figyelni, az pedig az alignment. A 8 * 0.5 k-s blokk ne legyen elcsúszva a valósághoz képest. Gondolom, ez azt jelenti, hogy a 4 kiB-os blokk címzésekor az LBA cím modulo 8 = 0 legyen.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Visszakérdezek: a hardver -- amivel pl. a diszket vezérled, vagy ami a diszken/adathordozón van vezérlő -- ,,papír szerint'' (azaz a gyári doksi szerint) milyen blokkméretet támogat legszívesebben?
Nem lenne esetleg célszerű erre a blokkméretre formázni az adathordozót?
Nem akkor a legnagyobb hatékonysága a lemezelérésnek (vagy adathordozó-elérésnek), ha a vezérlőn levő pufferek épp akkora méretű adatmennyiséget mozgatnak/tárolnak, mint amekkora a blokkméret?
G.
============================================
"Share what you know. Learn what you don't."
- A hozzászóláshoz be kell jelentkezni
Én vagy 4 kiB-os blokkmérettel használnám - ez a célszerűbb -, vagy 512 byte-ossal ugyan, de a partíciók LBA címeit szigorúan 8-cal osztható helyre tenném. Hasonlóképpen LVM esetén a PE is 4 kiB-tal osztható legyen, de ez nyilván teljesül.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Egyébként van mégy egy ilyen is, hogy:
cat /sys/block/sda/queue/hw_sector_size
Nálam a 4k-s SSD 512-nek hazudja magát.
Olyat már láttam, hogy 4096-os 512-nek hazudta magát, de fordítva még nem tapasztaltam.
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
- A hozzászóláshoz be kell jelentkezni