Portál AbcLinuxu, 3. května 2025 17:24

Mount a ISOFS

12.2.2006 18:40 | Přečteno: 1193× | 'enlightened'

V návaznosti na diskuse ohledně chování programu mount ve vztahu k filesystému ISO 9660 jsem ho rozhodl přesvědčit se, jak to doopravdy je. A je to v podstatě tak, jak jsem si myslel.

Spustíme-li program mount (s požadavkem připojit konkrétní FS), záleží na tom, zda existuje příslušná položka v /etc/fstab a jaké parametry mount dostane. Konkrétně třeba typ FS - největší prioritu má hodnota zadaná z příkazové řádky, pak následuje hodnota ze souboru, a teprve nakonec by se mount pokoušel o detekci filesystému.

Podobně je to i s volbami pro připojení. Tedy i s tím, zda se bude připojovat RO nebo R/W. Důležité je, že R/W je výchozí volba, a že detekce typu systému nemá žádný vliv na to, jak se filesystém připojí. Jinými slovy, že detekce (nebo jiné určení) filesystému ISO 9660 nezpůsobí, že by mount automaticky přepnul na RO. Stejně tak na to nemá vliv zařízení - bylo by to nesmyslné a nesystematické, znamenalo by to mj. pořádné nabobtnání programu.

Program mount tedy, v okamžiku kdy zná všechny potřebné parametry, volá syscall mount, který provede (samozřejmě v jádře) samotné připojení. Jádro zjistí typ filesystému a zavolá příslušnou funkci v ovladači tohoto filesystému. A zde je to klíčové - ovladač pro ISOFS totiž bez dalšího natvrdo nastavuje režim na RO (bez ohledu na to, jaké parametry dostal). Není sám, podobně postupuje třeba ovladač NTFS, pokud nebyl zkompilován s podporou zápisu.

Po připojení se běh vrací zpět do programu mount, a ten (pokud bylo připojení úspěšné) zapíše soubor /etc/mtab. Použije k tomu ty parametry, které posílal do jádra - nezajímá ho, jaké změny jádro provedlo (ostatně by si to musel zjistit, např. přes PROCFS, protože je přes syscall zpět nedostane).

Co z toho vyplývá? Že v /etc/mtab (pokud je vytvářen přímo programem mount) jsou parametry poskytnuté programu mount, kdežto v /proc/mounts jsou parametry, s jakými jádro filesystém připojilo. Proto ten rozpor.

Ještě zbývá vysvětlit rozpor mezi filesystémem připojeným ad hoc (na základě parametrů poskytnutých uživatelem) a systémem připojeným podle záznamů v souboru /etc/fstab. Záznamy do tohoto souboru dnes dělá většinou démon HAL (dříve třeba program kudzu apod.), který detekci schopností zařízení provádí (s jakou kvalitou, to nechme stranou). Proto, rozpozná-li RO zařízení, v řádku pro příslušný filesystém se objeví tato volba.

Doufám, že tento stručný přehled ukončí nesmyslné spory o to, co jaká komponenta dělá nebo má dělat. Já osobně považuji použitou koncepci za poměrně rozumnou, i když někdo může mít jiný názor.

       

Hodnocení: 94 %

        špatnédobré        

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Nástroje: Začni sledovat (0) ?Zašle upozornění na váš email při vložení nového komentáře. , Tisk

Vložit další komentář

12.2.2006 19:24 Jindřich 'GoldenShit' Plešinger | skóre: 16 | blog: Nevěřící | Dolní Bousov
Rozbalit Rozbalit vše Re: Mount a ISOFS
Odpovědět | Sbalit | Link | Blokovat | Admin
   Pokud má být Linux lepší než Windows, musí být použitelný pro běžného uživatele a toho nezajímá jak program mount pracuje. Bude pracovat v grafickém prostředí a pokud mu něco nepůjde, tak se zeptá někde na fóru a tam většinou dostane radu co napsat do terminálu.

   Pokud ho program při připojení CDčka s parametrem rw vyfakuje, je to dobře, ale pokud ho při připojení *.iso souboru nevyfakuje, tak je přinejmenším podivné a různorodé informace poskytující grafické programy, jede zapisovat a zároveň nejde, jsou přinejmenším matoucí.

   Nejspíše jde o problém odkud grafické programy berou informace o připojených filesystémech, ale pro odstranění matení uživatele, by se mohl program mount chovat jednotně. Buď ať fakuje vždy nebo nikdy.

Jinak děkuji za vysvětlení.
LINUKS = Lidová Nacionálně Ultralevicová Komunistická Strana
Luk avatar 12.2.2006 19:38 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
Rozbalit Rozbalit vše Re: Mount a ISOFS
Abych se přiznal, nevím, odkud bere který program informace. Jsem ovšem toho názoru, že např. KDE se v této oblasti nevyvíjí správným směrem. Jsem zvědav, co přinese verze 4, ale ta trojková na mě nedělá dobrý dojem. Už třeba tím, že když filesystém na CD odpojím, po nějaké době ho KDE znovu připojí (a otevře okno Konqueroru, resp. u zvukového CD spustí přehrávání). Nevím, jak to vypnout (zkusil jsem už všechno možné).
Šifrování je absolutní nutnost a pomáhá chránit před nekalými živly
13.2.2006 10:52 Jiří (BoodOk) Kadeřávek | skóre: 19 | blog: BoodOk | Brno
Rozbalit Rozbalit vše Re: Mount a ISOFS
Odpovědět | Sbalit | Link | Blokovat | Admin
Pokud byl vystupem nesmyslnych sporu tenhle blogpost, pak az tak nesmyslne nebyly. Ukazali, ze v tom ma malokdo jasno a tebe inspirovali k tomu to ujasnit. Aneb, vse spatne je pro neco dobre :-)
Věda má v sobě určitou zpupnost, že čím dokonalejší techniku vyvineme, čím více se dozvíme, tím lepší budou naše životy.
13.2.2006 11:29 Bubak | skóre: 16 | blog: Čtvrtá cenová
Rozbalit Rozbalit vše Re: Mount a ISOFS
Odpovědět | Sbalit | Link | Blokovat | Admin
Neni to tak uplne pravda, v urcitych pripadech zpravu o tom, ze system se pripoji nelze pripojit read/write a pripoji se readonly, dostane a parametry zapise spravne i do mtabu. Zjisti to u medii, ktera jsou fyzicky neprepsatelna, napr. CDROM, DVD, zamcena disketa.

Kdyz jsem tak koukal do zdrojaku, jsou tam mista, kde by se mozna mohlo zjistit, ze driver pripojil svazek readonly. Ale nemel jsem cas si to zkusit:-(. Urcite tam na jednom miste je hlaska, ze nelze zarizeni pripojit read/write a v options neni tento fakt promitnut, ale to se nas netyka, protoze to, co pise Plesa se deje potichu.
... máš jen mrtvou kočku a poškrábanýho jezevčíka ...

Založit nové vláknoNahoru

ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.