Dotaz: Mount btrfs na GPT

[camel1cz]

Hezký den,

nepotkal jste se někdo s problémem s mountem, resp. s neexistujícím /dev/sdbX pro partition, kterou chci mountovat?

Vyměnil jsem rootfs disk, protože odešel... dal sem tam novou minimální instalaci ubuntu 18 LTS a ne a ne.

# dmesg | grep sdb

[    2.798791] sd 1:0:0:0: [sdb] Host-aware zoned block device
[    3.002422] sd 1:0:0:0: [sdb] 15628053168 512-byte logical blocks: (8.00 TB/7.28 TiB)
[    3.002427] sd 1:0:0:0: [sdb] 4096-byte physical blocks
[    3.002430] sd 1:0:0:0: [sdb] 29808 zones of 524288 logical blocks + 1 runt zone
[    3.002476] sd 1:0:0:0: [sdb] Write Protect is off
[    3.002481] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[    3.002553] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    3.256847]  sdb: sdb1
[    3.256855] sdb: p1 start 2048+15628051087 is not zone aligned
[    3.462397] sd 1:0:0:0: [sdb] Attached SCSI disk

Podle toho to vypadá, že ta partition existuje, stejně tak fdisk:

# fdisk -l /dev/sdb

Disk /dev/sdb: 7.3 TiB, 8001563222016 bytes, 15628053168 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
Disklabel type: gpt
Disk identifier: 4E2D8B5A-3B7C-4D97-8B53-DAAE54488587

Device     Start         End     Sectors  Size Type
/dev/sdb1   2048 15628053134 15628051087  7.3T Linux filesystem

Podpora btrfs v jádře je, přidal jsem ho i do initrd. Ale stejně nechápu, proč tam to sdb1 není, když ho driver vidí.

---

---

Odpovědi

[frufru]

Že by systemd nedovolil přimountovat btrfs, i když to zadáš do initrd? On si totiž dělá co chce.Po vyhledání btrfs a systemd toho vyběhne docela dost.

[Peter Golis]

Ak neexistuje /dev/sdbX, tak čo vypíše príkaz partprobe -s /dev/sdb a ako je pripojený /dev o ktorý by sa mal starať udev ?

[camel1cz]

# partprobe -s /dev/sdb

/dev/sdb: gpt partitions 1

# mount | grep /dev\

udev on /dev type devtmpfs (rw,nosuid,relatime,size=3539252k,nr_inodes=884813,mode=755)

udev zjevně funguje, protože druhý disk je OK

# ls -1 /dev/sd*

/dev/sda
/dev/sda1
/dev/sdb

[Peter Golis]

A nebude na tom disku zabudnutá zlá MBR? Odporučil by som pozrieť aj gdisk -l /dev/sdb.

[camel1cz]

Disk jsem trápil v Ubuntu 16.04 tuším v fdisku... o fdisku sem četl v souvislosti s GPT nějaké divné věci, snad že dělá mezeru za partition table, ale to jde už mimo mě :(

# gdisk -l /dev/sdb

GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 15628053168 sectors, 7.3 TiB
Model: ST8000AS0022-1WL
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): BA9D1630-1222-7546-8868-614C9928EE60
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 15628053134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2021 sectors (1010.5 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048     15628053127   7.3 TiB     8300  

[camel1cz]

Ještě sem si teď všimnul, že se změnilo UUID té partition.

Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 84C23CE4-EA34-0541-AFDC-55EB43B216C5
First sector: 2048 (at 1024.0 KiB)
Last sector: 15628053127 (at 7.3 TiB)
Partition size: 15628051080 sectors (7.3 TiB)
Attribute flags: 0000000000000000
Partition name: ''

Ale původní UUID ve fstab mám:

e43cc284-34ea-4105-afdc-55eb43b216c5

To číslo je nějak jinak indiánové nebo co... nemůže to s tím souviset?

[debian+]

Vo fstab sa UUID pise velkym, tak si to prepis na velke pismena.

[camel1cz]

To je divný... řádek pro mount rootfs to založilo samo a je malýma a funguje.

Každopádně je primární problém ta neexistence sdb1, bez toho to nenamountím přes cokoliv.

[Andrej]

Vůbec nezáleží na velkých nebo malých písmenech. Tazatel se ptal na tu (na první pohled překvapivou) změnu pořadí bytů (mixed endian), což ovšem u GPT není nijak překvapivé; tak to prostě je. Už jsem to citoval níže, ale ještě jednou pro úplnost:

… The GUIDs in this table are written as per RFC 4122, i.e. big-endian byte order, recognizable by the position of the version bits. For example, the GUID for an EFI System partition (C12A7328-F81F-11D2-BA4B-00A0C93EC93B), when serialized in GPT data structures (little-endian), corresponds to the hex sequence 28 73 2A C1 1F F8 D2 11 BA 4B 00 A0 C9 3E C9 3B. The first three blocks are byte-swapped to little-endian, the last is a byte array. …

[multi]

Musis zjistit proc ti to neukazuje /dev/sdb1. Protoze pokud neni videt, tak ani neni co mountovat. Je dost mozne ze GPT mas porouchane...

[camel1cz]

No v tom starém systému vše fungovalo... a nebyl to stroj co běží roky a pak lehne a už nenaběhne. Rebootoval jsem to poměrně často a i před tím kixem jiného fyzického disku sem s tím cvičil a ten fisk fungoval normálně.

Ve starém fstab byl mountěný podle UUID, ale to samozřejmě také nejde, když není sdb1.

[camel1cz]

Tak jsem se k datům dostal přes loop device

losetup -v -f -o xxx /dev/sdb

Offset xxx se spočítá z výstupu fdisku - přepočet ze sektorů na bytes.

Řešení to ale není, nechce se mi překopírovávat data a znovu formátovat - je toho přes 6T.

PS: třeba mě nazvete lamou a BFU, ale btrfs mi nesmí do baráku - sem zase chtěl jít s dobou. Tohle se mi nestalo za celých 20 let s XFS a extX.

[Peter Golis]

No, jedná sa o rýchle riešenie ktoré funguje.

[frufru]

Tohle se mi nestalo za celých 20 let.... Tak si začni zvykat. Taky jsem to tak měl. To u mne chtěl Linuxmint připojovat btrfs, ale nedokázal to. Skončilo to hláškou Kernel panic - not syncing: VFS: unable to mount root fs on unknown-block(0,0). Divný bylo, že stále jedu jen na ext4 a chtělo to btrfs. A blblo to, když jsem tam měl Manjaro(arch) a linuxmint. Jo a procesor byl taky AMD. Zdá se, že tam mají v nastavení nějaký bug.

[lertimir]

To že se neobjeví blokové zařízení naprosto nesouvisí se souborovým systémem, takže obviňovat btrfs je mimo mísu. Daleko pravděpodobnější je, že máš nějakou chybu v nastavení oddílů na tom disku. I to že se změnilo UUID oddílu je spíše signál, že jsi na partition table nějak (i nevědomky hrábl) a nebo je možné, že ta chyba je delší dobu a jádro v 16.04 tu chybu ignorovalo a nějak se přes ni přeneslo a jádro 18.04 je už striktní.

[NN]

Toto:

[    3.256855] sdb: p1 start 2048+15628051087 is not zone aligned

by mohlo hrat roli?

[lertimir]

A přidávám ilustraci můj výpis k 8TB disku

pro 27 15:28:35 dnopytle kernel: sd 5:0:0:0: [sdg] 15628053168 512-byte logical blocks: (8.00 TB/7.28 TiB)
pro 27 15:28:35 dnopytle kernel: sd 5:0:0:0: [sdg] 4096-byte physical blocks
pro 27 15:28:35 dnopytle kernel: sd 5:0:0:0: [sdg] Write Protect is off
pro 27 15:28:35 dnopytle kernel: sd 5:0:0:0: [sdg] Mode Sense: 00 3a 00 00
pro 27 15:28:35 dnopytle kernel: sd 5:0:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
pro 27 15:28:35 dnopytle kernel: sd 5:0:0:0: [sdg] Attached SCSI disk

Není tam nic o zónových záležitostech, takže asi nemám SMD disk, protože z Archu mám dosti nové jádro 5.4.6 a je možné, že přístup k zonovým věcem se změnil mezi jádry z 16 a 18 buntu.

[Andrej]

PS: třeba mě nazvete lamou a BFU, ale btrfs mi nesmí do baráku - sem zase chtěl jít s dobou. Tohle se mi nestalo za celých 20 let s XFS a extX.

Prosím nešiř tady takový nesmyslný FUD. Tenhle problém nemá nic společného s Btrfs. (Kdyby se tohle stalo s oddílem s Ext4, sváděl bys to potom na Ext4? (Tipuju, že ne. Takže, nač ten dvojí metr?))

Souborový systém přece nemá žádnou kontrolu nad tím, co jsi udělal s tabulkou oddílů v nějakém starém Ubuntu, nebo nad tím, jestli ten oddíl máš nastavený jako hidden nebo něco podobně exotického, jestli sis náhodou nenastavil ignorování toho oddílu v udev pravidlech atd. atp.

Co říká udevadm monitor během připojování toho disku?

Když už máš možnost přečíst a zazálohovat tabulku GPT s přesnými hranicemi oddílů, co takhle zkusit celou tabulku smazat a znova vytvořit? Čistě jen tak pro ujištění, že v ní není nic špatného či neobvyklého. Ale rozhodně bych napřed zkusil udevadm monitor a udev obecně.

Pokud jde o UUID toho oddílu a pořadí bytů, stačí jenom nahlédnout do Wikipedie:

… The GUIDs in this table are written as per RFC 4122, i.e. big-endian byte order, recognizable by the position of the version bits. For example, the GUID for an EFI System partition (C12A7328-F81F-11D2-BA4B-00A0C93EC93B), when serialized in GPT data structures (little-endian), corresponds to the hex sequence 28 73 2A C1 1F F8 D2 11 BA 4B 00 A0 C9 3E C9 3B. The first three blocks are byte-swapped to little-endian, the last is a byte array. …

Prý jsi chtěl jít s dobou… V roce 2019? Jo, kdybys používal Btrfs třeba v roce 2009, tenkrát bys možná šel s dobou. Dnes bych nutnou samozřejmost (tj. souborový systém s checksumy, RAIDem a copy-on-write) neoznačoval termínem "jít s dobou".

(Nedá se nic dělat; pro některé uživatele je ExtX se svým designem z 90. let (pro disky o velikosti jednotek GB), s absencí datových checksumů, snapshotů i RAIDu a se silent data corruption pořád jaksi záhadně atraktivní.)

[camel1cz]

Jo, máš pravdu... vlastně ve všem až na tu poznámku o "jít s dobou" s kterou by se dalo polemizovat... ale to je fakt mimo téma. Souhlasím, že btrfs za to nemůže (a ani nemůže moct) a byl to můj frustrovaný výlev a reakce na něco co nechápu.

Zkouším to na úplně nové instalaci ubuntu 18.04, takže žádný ignore tam nebude...

...rozhodně bych napřed zkusil udevadm monitor a udev obecně.

Neumím ten disk připojit jinak než přes tu berličku s loop device, takže se v udev nic kolem té neexistující partition nehne. Mohl bys naznačit, jak to mám zkusit? Zapnul jsem akorát logování udev při bootu a zde je výsledek

Zkusil sem i udělat novou prázdnou partition table v gfisku (přes "o" a "n") a v ní znovu tu samou partition (jen trochu delší) a chová se to stejně. Ty GUID jsem netušil - měl sem strach, že to může souviset.

[GeorgeWH]

Neporadim a mozno trochu OT, ale podobny problem riesil nedavno kolega, ked mu nechcel nabootovat centos. Jadro particiu videlo, videl ju aj f|gdisk, parted..., ale ramdisk skoncil na tom, ze particia neexistuje (resp. /dev/sdaX). Uz neviem presne ako to vyriesil, ale tusim upravoval nejaky skript v ramdisku. Bola to ale rucna instalacia cez yum (chroot), aj ked tento sposob pouzivame uz roky, a dany problem sa v poslednje dobe vyskytol asi 2-krat.

[Filip Jirsák]

toto chovanie je sposobene tym ,ze particia nieje zarovnana na SMR zony. preto tuto particiu linux kernel umyselne ignoruje.

Finally, if a partition start sector is not at the beginning of a sequential zone, it will be impossible to write to the first sectors of the partition on a host-managed device. Avoid all these problems and incoherencies by ignoring partitions that are not zone aligned.

tvoj disk podporuje Host-Aware SMR , aky je to model?

[camel1cz]

Zní to jako trefa do černého! Super!

Bohužel nevím, co to je SMR :(

Info o disku:

Device Model:     ST8000AS0022-1WL17Z
Serial Number:    Z840QW12
LU WWN Device Id: 5 000c50 0929a7e67
Firmware Version: SN01
User Capacity:    8,001,563,222,016 bytes [8.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5980 rpm
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-3 T13/2161-D revision 3b
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Mon Dec 30 19:06:23 2019 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Product manual v PDF

[qhqhq]

o SMR si mozes vela precitat na internete, https://notebook.cz/clanky/technologie/2017/sindelove-disky-a-smr-zapis https://diit.cz/clanek/recenze-8tb-seagate-archive

konkretny model ktory mas je urceny na archivaciu dat. ja mam presne ten isty disk, mne to sposobovalo problemy s cryptsetup LUKS. vyriesil som to pomocou passtrough LUN do virtualu FreeBSD.

[camel1cz]

Vypadá to, že je to opravdu těmi zónami.

Nástin postupu, jak správně vytvořit partition je zde.

Bohužel disk, co jsem koupil (obdobný) je nejspíš vadný - nereaguje ani na smartctl, takže to teď nezkusím zformátovat.

Díky za nasměrování!

[qhqhq]

nemusi byt vadny, ak si na nho zapisoval viac ako 20gb dat tak je mozne ze si mu zaplnil konvencnu zonu na nahodne zapisy a iba treba pockat dokym to poupratuje, malo by to trvat niekolko hodin. to je bezne u vsetkych SMR diskov.

da sa to rozoznat podla toho ze je pocut aktivitu hlaviciek a pritom iostat ukazuje same nuly.

[camel1cz]

OK, ještě mu dám šanci. Někde sem se dočetl, že umře i když se zapisuje na špatná místa (viz ty zony). A že se musí uplně odpojit od napájení, aby se vzpamatoval.

Ty teda nemáš zkušenosti na linuxu? Myslíš, že stačí vyrobit ty zarovnané partition?

[qhqhq]

nenazyval by som to ze umre, jednoducho nestiha prepisovat zony na pozadi. treba vyskusat zarovnanu particiu, mozno to pojde. ja mam disk plny viac ako na polovicu takze to neplanujem u mna prerabat v najblizsej dobe.

[lertimir]

Takže je to asi tak, jak jsem ti psal dříve, buntu 16 chybu v zónách ignorovalo buntu 18 ne. Disk hlavně nemůžeš brát jako normální disk s náhodným write přístupem. SMR je zhruba řešeno jako tašková střecha. Když chceš vyměnit jednu tašku, potřebuješ přeskládat celou střechu. (zónu) Takže pokud tam máš archiv fotek, videí do kterého málo píšeš super. Pokud je to běžný pracovní disk, tak si musíš být vědom, že ten disk zapisovaná data chytne do své cache a pak následně později až má čas a není otravován přepíše celou příslušnou zónu. A z toho plyne jednak zátěž disku a jednak následný problém když se zaplní velkými náhodnými zápisy většina cache a disk nestíhá přepisovat zóny.

[j]

Proste a jednoduse, SMR sragory si kupujou jen zoufalci, kteri netusej co to je.

Super to totiz neni ani na ty videa, protoze je na to budes zapisovat mesice ... ono to totiz pri zapisu, v nejlepsim pripade, dava neco kolem 20MB/s ... realne klidne neco kolem 5MB/s. To ma leckdo internet rychlejsi, takze to nestihne zapisovat ani to co stahuje.

Pri cteni to pak taky neni zadna hitparada, zatimco normalni disk nema problem jit pres 100MB/s, tyhle sragory se horko tezko doplizej na 50, a to kdyz mas doslova zprdele kliku.

Prodejci kterej to prodava bez upozorneni by pak bylo treba nacpat hlavu skrz jeho rit do krku!

[Heron]

Mě spíš děsí ta kamufláž za klasický disk. Jako bral bych, kdyby se to chovalo prostě jako páska. Zápis je možný pouze kontinuálně a dejme tomu po těch zónách (takže x pásek). A toto by bylo exportováno do OS.

Ne, místo toho se to snaží tvářit jako normální disk (blokové zařízení s náhodný přístupem), v OS je na tom úplně normální FS, který je připraven na všechno ostatní, ale na tohle teda vůbec, pod tím je disk ve formě pásek a k tomu je tam bůh ví jak velká cache a firmware, který se na jedné straně tváří jako block device a na druhé má pásky. Jako tohle nemůže dopadnout dobře.

[Peter Golis]

Nedal by sa ten disk sformátovať na Linear Tape File System?
</joke>

[lertimir]

Tu kamufláž máš také na SSD. Kdysi jsem psal, že by bylo správné, aby výrobci SSD posílali ven reálné údaje a ne kamufláž jako disk. A za těch skoro 8 let se nic nezměnilo, naopak, co se v SSD děje, nevíme už nyní nic.

[Heron]

A nezměnilo se tohle s NVMe? Už se to nesnaží tvářit jako SCSI a má to i vlastní multiqueue (na hw open channel) na rozdíl od klasických elevátorů (což je výmysl pro klasické disky s hlavičkou).

[lertimir]

jenže podle mne na to potřebuješ speciální filesystem. Pokud to ssd je ochotno hlásit velikost write a delete bloku, a ke každému delete bloku přesnou informaci, tedy kolikrát byl přepsán a kolik write bloků v něm je zapsaných a kolik volných, tak podle toho můžeš vytvářet a optimalizovat FS přesně na tento HW. Standardní optimalizace FS je na rotační disky. možná by se mohlo uvnitř toho delete bloku pracovat nějak jako NILFS. Ale to co je zvláštní, že jsem nikde nezaznamenal, že by to někoho zajímalo, ani na technických univerzitách jako MIT to nevypadá, že by to někdo řešil, takže možná mám v úvaze nějakou chybu, která není zřejmá.

[citanus]

Tak poté, co jsem nastudoval o čem je SMR a vyreklamoval vadný kus mi dovolte dílčí report stavu.

Úvodem: tyhle SMR a.k.a. archivní disky používám na to, na co jsou určené - teda zápisy velkých bloků dat (typicky zálohy v archivech nebo velké soubory - převážně zvuková data). Filesystem btrfs.

Mám teď v provozu 6 disků, obchodně jsou stejné, ale technicky se liší - 4 starší jsou "host-aware" SMR (konkrétně Seagate ST8000AS0022) a nové dva jsou transparentní (konkrétně Seagate ST8000DM004). Všechny mají kapacitu 8TB.

Transparentní disky jsou rozděleny běžným způsobem a vůbec je neřeším. Fungují normálně. Zásek nastal s těmi staršími "host-aware" - po aktualizaci kernel začal vynucovat zarovnávání partition na zóny disku, což historicky nebylo.

Původní dotaz vznikl právě proto - po upgrade kernelu (resp. celého systému) začal být kernel obeznámen se SMR a protože partition neseděla na zóny disku, odmítl s ní pracovat. Řeším to tedy tak, že na nový disk přesunuju ten starý a pak udělám přepartyšnování a data nahraju zpátky.

Vše další je tedy o zápisek na tu novější variantu disku.

Ke zkušenostem: zkráceně spokojenost, jsem schopen zapisovat soustavně víc jak 110GB za hodinu. V režimu cca. 20 minut zápis a 40 minut relativní klid (zapisuje se druhým procesem nonstop, ale o řád míň dat). Rychlost dostahuju přes 100MB/s v tom jedno procesu... teď zkouším ještě dvojnásobný objem dat za hodinu, vždy 20 minut zápis, 10 minut klid. Zatím to disk zvládá i tak, ale je to teprve pár hodin a disk může ještě mít nějaké místo v cache.

Ještě napíšu jak to vypadá dál se zápisem větších objemů dat a na host-aware disky - jen pro info, kdyby to někdo řešil.

Jediné, co je divné je, že se ve SMART inkrementují countery, některé se časem resetují - to jsem zatím neprokouknul, ale předpokládám, že data mají jinou interpretaci než u klasických disků. Jde hlavně o Raw_Read_Error_Rate, Seek_Error_Rate, Command_Timeout a Hardware_ECC_Recovered. V syslogu není mimo smart hlášení o změnách nic. Žádné IO chyby kernelu.

Zajímavé odkazy:

Co jsou SMR disky

Jak zjistit co mám: sysfs, utility a

dmesg | grep sd?

Jak na partitions na disk-aware disku (poslední reakce)

[lertimir]

u Seagate se Raw_Read_Error_Rate inkrementuje podle skutečného čtení na disku. Před cca 8-10 lety jsem tento udaj používal k zjistění kvality povrchu a případné reklamace u nového disku. Postup byl takový, že jsem dal formátování (tedy zapsat a přečíst) celý disk a při čtení jsem pravidelně snímal hodnotu RRER řekněme každých 20 vteřin. counter se sice točí cyklicky, ale v grafu bylo jasně vidět že disky měly v ruzných částech povrchu různou rychlost přibývání counteru. což jsem interpretoval jako informaci o kvalitě povrchu. pokud rychlost nebyla moc velká a byla rozumně stabilní přes celý disk, disk jsem bral. Pokud měl části kdy RRER obrovsky zrychlilo disk jsem vracel. WD disky tam mají abstraktní numero většinou nulu a neco nenulového až když je problém.

Se SMR nemám zkušenosti