Dotaz: Jak je možné zjistit velikost výstupní roury?

[Aleš Janda]

Mám tento příkaz:

pv /dev/zero > /dev/sdaX

Program "pv" vezme obsah souboru /dev/zero, kopíruje ho na výstup a do toho ukazuje průběh. Pokud je vstup nějak omezen (např. je to normální soubor), ukáže kolik toho má v procentech, zbývající čas atd. Pokud neví (např. vstupem je roura), ukazuje jen kolik přenesl dat. Zařízení /dev/sdaX je pak normální fyzický disk, který má nějakou velikost.

Ve výše zmíněném případě má k dispozici pv jen zařízení /dev/zero, které je nekonečné, a zapisuje na svůj standardní výstup, který by měl být (pro něj) také nekonečný.

Tak to ale není! Ve skutečnost pv (správně) zobrazil průběh tak, že počítá s celkovou velikostí /dev/sdaX! Jak je to možné? To přesměrování do zařízení přece zařídil bash, ne? Jak se pv dozví velikost něčeho, co je schované za rourou?

Díky

---

---

Odpovědi

[Josef Kufner]

Jednoduše. Nijak se to nedozví.

Dokonce i kdyby zapisoval do souboru a ne do roury, tak nebude vědět, neboť soubory při zápisu nemají explicitně omezenou velikost. Může si bokem zjistit, jak je na tom filesystém, kam se ukládá, ale ani to není jisté, navíc se situace může snadno změnit během zápisu. Ani pokud se zapisuje přímo na blokové zařízení, tak není jisté, že se jeho velikost nezmění – např. pokud by to byl LVM oddíl a někdo do něj přidal disk; ten program může jen hádat, zda na druhé straně souboru je fyzické zařízení.

Nejlepší a asi i jediné, co můžeš udělat, je explicitně říct pv, jak je cíl/zdroj velký:

pv -s `blockdev --getsize64 /dev/sdaX` /dev/zero > /dev/sdaX

[Aleš Janda]

Právě že se to nějak dozví:

# pv /dev/zero > /dev/sdc
 644MiB 0:00:12 [4,37MiB/s] [>                      ]  1% ETA 0:18:25

(všimněte si toho odhadu času, procent apod.)

Když dám mezi pv a zařízení ještě třeba gzip, tak už tam žádný odhad není.

[Josef Kufner]

Hm, koukám, že jsem si to pěkně blbě přečetl.

[Aleš Kapica]

No, vzhledem k tomu že zařízení /dev/sdaX existuje a z pohledu linuxu má předem známou velikost, je vcelku logické že ti projede přes PV jen tolik dat, kolik se ně vejde.

Nekonečně můžeš jet podle mě leda když necháš pv jet z /dev/zero do /dev/null

[NN]

Mas to v manualu:

Zeroing a disk:

pv < /dev/zero > /dev/sda

Note that if the input size cannot be calculated, and the output is a block device, then the size of the block device will be used and pv will automatically stop at that size as if -S had been given.

[Aleš Janda]

No jo, to je přesně ten případ, o kterém píšu. Jak je to ale možné? Jak může pv zjistit „size of the block device“ když je to pro něj jen výstupní roura? (Skutečně je to jen roura, když se podívám htopem na spuštěný příkaz, je tam přesně ten příkaz, co jsem zadal, tedy „pv /dev/zero“.)

V tom manuálu je to ještě okořeněné o to, že zjevně umí zjistit i velikost vstupu. A opravdu – když zadám

pv < soubor | další příkazy…

pv se nějak domákne velikost toho vstupního souboru. Když zadám

cat soubor | pv | další příkazy…

už tu velikost nezjistí. V čem je ten rozdíl? Lze nějak zjistit typ roury, co za ní „sedí“?

[Josef Kufner]

Trik je v tom, že > není roura, ale přesměrování. Když uděláš pv > soubor, tak shell otevře soubor a tím na něj získá file descriptor. Když pak shell spustí pv, tak mu tenhle file descriptor předá (spolu s stdin/err, co vedou na terminál), takže ve výsledku je situace stejná, jako by si pv ten soubor otevřelo samo. Pak už stačí zavolat nějaké to ioctl a zjistit, co je potřeba.

Pokud se použije |, tak shell vyrobí nepojmenovanou rouru, čímž získá dva file descriptory – jeden na začátek a druhý na konec. Stejným způsobem pak jednotlivé file descriptory předá odpovídajícím programům. Takže když pak pv chce použít ioctl jako předtím, tak je za file descriptorem roura a ne blokové zařízení.

[Aleš Janda]

Jo aha, ioctl se vlastně volá přímo na file descriptor! Čili i z „roury“ lze poznat, jestli to je roura nebo soubor. Že mě to hned nenapadlo. To je ono, díky

[mimi.vx]

stale si pletes dva pojmy ... roura (|) a presmerovani (> , >> , < , <<) .. U roury to fakt neni jak zjistit

Náš administrátor shledal tento komentář závadným.

trolling

Zobrazit komentář