Zpravodaj o Víně – 31. 3. 2013: Mandatorní zamykání souborů na Linuxu

10. 4. 2013 | Luboš Doležel | Různé | 5070×

Nové verze Wine. Mandatorní zámky souborů na Linuxu. Jak analyzovat výkon D3D. Změny v databázi aplikací.

Nové verze Wine

Wine 1.5.26 vyšlo 15. března s těmito změnami:

• Podpora OpenGL v ovladači Mac.
• Podpora schránky a drag&drop v ovladači Mac.
• Vylepšení v URL cache.
• Nějaké opravy pro binárky pro ARM.
• Platforma SPARC již není podporována.
• Různé opravy chyb.

Wine 1.5.27 vyšlo 29. března s těmito změnami:

• Podpora systémové lišty v ovladači Mac.
• Ruzná vylepšení runtimu C.
• Velké ikony pro vestavěné aplikace.
• Různé opravy chyb.

Mandatorní zámky souborů na Linuxu

Lepší podpora zamykání souborů proti čtení/zápisu je něco, o čem se na LKML diskutovalo už před několika lety. Nyní se tento nápad vrátil a souběžně s tím se podpora této funkce řeší i ve Wine. A důvod? Tato funkce je používána především na Windows; na Linuxu sice historicky podpora pro zamykání souborů existuje, ale její užívání (a respektování) je naprosto volitelné. Přesněji řečeno: najít linuxovou aplikaci, která zamykání používá nebo alespoň respektuje, dá docela zabrat.

Kromě Linuxu se tento námět objevil i na mailing listu NetBSD.

Příznaky O_DENY* se od flock odlišují tím, že práce s nimi je atomická – o případném neúspěchu se tedy dozvíte už při otevírání souboru pomocí open() a uzamčení můžete rovněž provést už při otevírání. Zatím to ale vypadá, že i tak bude mechanismus O_DENY* nějakým způsobem volitelný (aplikace NEBO systémy nepoužívající příznak „chci respektovat zámky“ nebudou ovlivněny), protože uživatelé unixových systémů nejsou na tuto „šikanu“ z Windows navyklí a zvykat si nechtějí, proto ani nepřekvapí, že se podpora zamýšlí hlavně do síťovýcḧ systémů souborů CIFS a NFS.

Toť úvod. Jadernou část diskuze ponechme do případných Jaderných novin a podívejme se na debatu, která se odehrála na wine-devel. Pavel Shilovsky (mluvící o patchi pro Linux):

Tento patch přidává podporu příznaků O_DENY* do linuxové souborové vrstvy. Tyto příznaky mohou být používány libovolnou aplikací, která potřebuje používat řízení přístupu k souborům. VFS už podobnou schopnost má – nyní se to dělá přes mechanismus flock/LOCK_MAND, ale tento přístup není atomický. Tento patch přidává nové schopnost navrch existující podpory, ale nemění nic na voláních flock.

Příznaky mohou být používány v serverech NFS (vestavěných do jádra) a CIFS (Samba) a v aplikacích ve Wine skrze VFS (pro místní systémy souborů) nebo moduly CIFS/NFS. Toto pomůže například tehdy, kdy Samba a NFS server sdílejí ten samý adresář pro uživatele na Windows a na Linuxu nebo aplikace ve Wine používají sdílení Samba/NFS pro přístup ke stejným datům z různých klientů.

Vzhledem k předchozím diskuzím je nejpalčivější otázkou to, jak zabránit situacím jako DoS útokům, kdy např. /lib/liba.so může být otevřeno s příznakem DENYREAD nebo něčím takovým. To je důvod, proč je navíc přidán příznak O_DENYMAND. Nižším vrstvám se tak dává najevo, že aplikace chce používat vlastnosti příznaků O_DENY*. Zamezuje to dopadu na nativní linuxové aplikace (které O_DENYMAND nepoužívají) – takže tyto příznaky (a s tím spojená sémantika systémového volání open) jsou používány jen u aplikací, které to chtějí.

Takže tedy máme čtyři nové příznaky:

• O_DENYREAD – zamezí ostatním číst
• O_DENYWRITE – zamezí ostatním zapisovat
• O_DENYDELETE – zamezí ostatním mazat (tento příznak není implementován ve VFS a NFS a hodí se tedy jen pro CIFS)
• O_DENYMAND – vypíná/zapíná předchozí tři příznaky

[...]

J. Bruce Fields se ozval s tím, že mu tento polovičatě mandatorní přístup nepřijde zrovna dobrý.

Mám tak trochu obavy: jde o mandatorní zámky a aplikace, které je používají, jsou zvyklé na to, že jsou správně vynucovány. Jsme si jistí, že aplikace, která otevře soubor s O_DENYWRITE nehavaruje, jakmile jí někdo bude pod rukama měnit data?

Obecně jsem z nápadu mít volitelně povinné zamykání nervózní. Raději bych viděl něco jako volbu pro mount, aby všichni věděli, že ostatní hrají na tomto systému souborů podle stejných pravidel, ale stále bychom měli možnost mít systémy souborů jako / bez této volby.

Zbytek diskuze se dále točil okolo volitelnosti těchto zámků. Zatím to vypadá, že se všichni (snad i včetně autora patche) přiklánějí k nové volbě pro mount.

Jak analyzovat výkon D3D

Implementovat Direct3D navrch OpenGL je pracné. Dosahovat srovnatelného výkonu je ještě pracnější. Sám se o tom přesvědčuje Graham Knap, kterému vadí nižší výkon StarCraft II pod Wine:

Rád bych pomohl se zlepšením výkonu StarCraftu II pod Wine. Pracuji na tom s kamarádem. Během uplynulých týdnů jsme se snažili číst veškerou dokumentaci, co jsme našli. Různými způsoby jsme se to snažili profilovat, bez výrazného úspěchu.

Můj kamarád rozchodil WineD3D pod Windows. Sestavili jsme Wine z aktuálních zdrojáků, zkusili jsme to na dvou různých konfiguracích a máme podobné výsledky. [...]

Vypadá to, že WineD3D je příčinou většiny rozdílu ve výkonu. Windows se svým D3D nám dávají alespoň dvojnásobné FPS než Windows + WineD3D. Je tam i rozdíl mezi Windows + WineD3D a Linux + Wine, ale ten je mnohem menší, takže třeba něco jako 25 %.

Mohl by nám někdo poradit, jak najít nejvýznamnejší příčiny rozdílu ve výkonu? Nějaké tipy, jak to efektivně profilovat nebo trasovat?

Přispěchal Stefan Dösinger, který upozornil, že zlepšení výkonu není něco, co by se dalo vyřešit jen tak za víkend. Dále řekl, že je nutné rozlišovat mezi nedostatkem výkonu CPU a GPU. Pokud má změna rozlišení za následek výrazný rozdíl ve FPS, pak je problém zjevně v povelech pro GPU. Pokud zůstane výkon podobný, pak je zádrhel přímo na straně softwaru, kterému nestačí výkon CPU.

Graham za několik dnů přišel s informacemi, jak to vlastně je. A podle všeho výkon omezuje CPU:

Jak jsem uvedl v bugu Wine #24558, musím použít taskset, abych dostal vůbec nějaký rozumný výkon.

$ taskset -a -p 2 `pidof SC2.exe`
$ taskset -p 1 `pidof SC2.exe`

Nejsem si jist, jestli to je vůbec chyba ve Wine. Řekl bych, že je to jen odlišnost v plánovači OS a správě výkonu. SC2 by asi mělo nastavit CPU affinity, ale neřekl bych, že to dělá.

Nastavení detailů grafiky a rozlišení obrazovky nemá na FPS velký vliv, takže si myslím, že nás omezuje CPU.

Na návrh zkusit omezit používaná CPU přímo ve Windows pak odpověděl:

To má rozhodně vliv. FPS během drobné nahrané bitvy:

• Linux + Wine: okolo 18 FPS
• Windows XP (nativní D3D) s 1 jádrem: okolo 48 FPS
• Windows XP (nativní D3D) se 2 jádry: okolo 67 FPS

Graham pokračoval výčtem způsobů, jak se snažili příčinu nedostatečného výkonu odhalit. Zkoušeli i nástroj perf, ten ale nedokázal ani při kompilaci s -ggdb pojmenovat symboly adresy v některých knihovnách Wine. Debata pak bohužel ustala.

       

Komentáře

[Ovocníček]

Jo, to zamykání, to je věc. x264 se pro Windows kompiluje pomocí MinGW (Ming Nemilosrdný...), takže to pochytilo tyhle unixové móresy.

Už se mi stalo, že při nechtěném spuštění další instance enkodéru přepsalo druhé x264 tomu prvnímu jeho výstupní soubor (o velikosti několika GB). Ani jedna z instancí si vůbec nevšimla, že se děje nějaká nepravost (i když došlo k totálnímu znehodnocení výstupu) a vesele pokračovaly v už zbytečném enkódování.

Bylo to svým způsobem i legrační - ten enkodér, co byl pozadu, zkrátil výstupní soubor na nulu (a postupně pak začal přidávat), pak ten první enkodér, který už měl několik giga hotových, když chtěl zapsat další data, zase začal zapisovat tam, kde si myslel, že předtím skončil, čímž se soubor opět nafoukl nulami na původní velikost... akorát teď nevím, jestli pak ten druhé enkodér přepisoval vnitřek toho souboru, nebo pořád zkracoval.

[j]

Na druhou stranu, miluju widli aplikace, ktery odmitnou cist soubor s tim, ze je zamceny pro zapis ... uzasny trebas kdyz clovek sosa nejaky to video a chce se podivat, jestli je to to, co to o sobe tvrdi ..., pripadne jak moc kvalitni je obraz. Nastesti mplayer na zamky kasle ;D.

[Ovocníček]

Záleží to na aplikaci - některé to zamknou tak, že se k tomu nedostanete ani tak (třeba virtualdub, co mě tak napadá), protože jsou zamčené i pro čtení asi. Většinou je to ale zamčené jen pro zápis, a to potom závisí od etevírajícího programu, jestli si požádá o rw nebo ro.

[Sten]

Nechtěné spuštění další instance je ale problém uživatele, ne systému

Btw. jako chyba toho programu by se dalo brát, že se nezeptal, jestli to má přepsat. Ale konzolové programy se většinou neptají.

[Ovocníček]

To je sice pravda, ale snadno se tomu zabrání. Počítám, že taky nebrojíte proti hláškám typu "opravdu chcete naformátovat tenhle oddíl?". Nebo nechcete, aby vám správce souborů mazal nevratně soubory po stisknutí delete bez potvrzení.

[Ovocníček]

Tedy, snadno se tomu dalo zabránit.

[luky]

To je sice pravda, ale snadno se tomu zabrání. Počítám, že taky nebrojíte proti hláškám typu "opravdu chcete naformátovat tenhle oddíl?". Nebo nechcete, aby vám správce souborů mazal nevratně soubory po stisknutí delete bez potvrzení.

Takovehle hlasky nastesti nikde nemam a doufam, ze se to nezmeni. K cemu ta hlaska je, to jako testuje, jestli jsem behem par us, nez se objevi, nezmenil nazor?

[Ovocníček]

Ne, to testuje, jestli jste tu klávesu nezmáčkl omylem nebo vám na ní nešlápl kocour.

[luky]

Pokud kocour dokaze chozenim po klavesnici temer naformatovat disk, tak mu to potvrzeni asi uz nebude delat problem. A ochrana proti chybam maji byt zalohy a ne prudici dialogy.

[Ovocníček]

A ochrana před bouračkou dobrá pojistka? :D

[luky]

Ne, pojistka je ochrana pred nasledky, stejne jako zaloha.

[Ovocníček]

Právě - a tady je mi podsouváno, že bych se měl zaměřit na boj s následky problému, místo toho, abych se pokus problému vyhýbat.

[little.owl]

... nebo vám na ní nešlápl kocour.

Tohle je bezesporu zásadní problém. Ty bestie chlupaté se totiž strašně rádi válí na klávesnici na které právě někdo pracuje a program který to nebere v potaz je jednoduše špatně navržen.

[Michal Vyskočil]

Náš kocour nejraději zacpával větrací otvor, ale ani klávesnicí nepohrdnul. Ono taky udělat kočko odolný notebook znamená zařídit, aby produkoval minimum zbytkového tepla ...

[Sten]

mkfs se neptá, jestli má formátovat, prostě konzolové aplikace předpokládají, že víte, co děláte. Pokud chcete něco, co se ptá, použijte klikací aplikaci.

[luky]

Jo, to zamykání, to je věc. x264 se pro Windows kompiluje pomocí MinGW (Ming Nemilosrdný...), takže to pochytilo tyhle unixové móresy.

Už se mi stalo, že při nechtěném spuštění další instance enkodéru přepsalo druhé x264 tomu prvnímu jeho výstupní soubor (o velikosti několika GB). Ani jedna z instancí si vůbec nevšimla, že se děje nějaká nepravost (i když došlo k totálnímu znehodnocení výstupu) a vesele pokračovaly v už zbytečném enkódování.

Bylo to svým způsobem i legrační - ten enkodér, co byl pozadu, zkrátil výstupní soubor na nulu (a postupně pak začal přidávat), pak ten první enkodér, který už měl několik giga hotových, když chtěl zapsat další data, zase začal zapisovat tam, kde si myslel, že předtím skončil, čímž se soubor opět nafoukl nulami na původní velikost... akorát teď nevím, jestli pak ten druhé enkodér přepisoval vnitřek toho souboru, nebo pořád zkracoval.

Todle chovani je velmi zadouci v pripade, ze chcete zkratit logovaci soubor nejakeho demona.

[Ovocníček]

No sorry, ale v takovém případě máte použít nějaký k tomu určený názor. Omlouvat takovouhle "užitečností" fundamentálně střelenou koncepci je IMHO intelektuálně mimo.

Až mi shoří barák, tak se taky nebudu utěšovat tím, že si těma sazema co zbydou na spáleništi můžu natřít ksicht, abych nebyl vidět, až budu v džungli číhat na predátora. :D

[smazáno]

Vzdyt ty mandatorni locky fakt jen otravujou. Srovnej si jak se ve Windows/Linuxu napriklad chova, kdyz vyexportujes dokument do pdf a to pdf mas zaroven otevrene v evince/acrobatu. Windows te donuti ho zavrit pred tim nez exportujes, v linuxu ho evince proste updatuje.

[Ovocníček]

Proč exportuješ do soubouru, co už existuje? Jinak to není pravda u všech programů, závisí to na jejich programátorovi, jaké chování si vybere - třeba np++ si nechá klidně soubory smazat.

[smazáno]

Ja netvrdim, ze se to nad tim API napsat neda, ale rikam, ze Windows v tomhle tezce saje z uzivatelskeho pohledu.

[Kaero]

"Proč exportuješ do soubouru, co už existuje?" - asi protože v pdf si všimnu že tam je nějaká chyba, opravím ji a výstupní pdf vygeneruju znova.

[Jesus Jimenez]

A proc bych neexportoval? Kdyz si testuju sablony a generuju reportlabem PDFka, tak to delam prave takhle. A evince mi ten soubor reloadne.

[Ovocníček]

No jo, ale je majoritní případ že A) exportuju nový soubor a nechci aby se mi přepsal jiný, když si spletu jméno, nebo B) exportuju znovu a chci přepsat starší verzi? Podle mě A), a je teda lepší být opatrný, protože v tom minoritním případě tu hlášku člověk vždycky snadno odklikne... Jestli by vám to Evince nedovolilo přepsat, tak to by asi byla jeho chyba - coby prohlížeč by asi soubor nemělo zamykat. Pokud by ovšem byl soubor otevřený nějakým editorem, tak to už se IMHO dá argumentovat, že by ten soubor zamčen být měl, aby se předešlo nepříjemným překvapením.

[smazáno]

Hele, chapu, ze te jednou vypekl x264 encoder, ale spravne reseni by bylo, aby se te zeptal jestli chces pokracovat, i kdyz soubor uz existuje (na to je v unix konvenci prepinac -f).

To jak tu svou spatnou zkusenost zobecnujes na potrebu mandatornich locku je skoro az trapne (a neco mi rika ze stejne jen trollujes), protoze moderni desktop je o tom aby mezi sebou jednotlive programy seamlessly komunikovali.

[Ovocníček]

No já vám nevím. Tady je IMHO problém, že si nechá do souboru nasrat ta první instance. A to co navrhujete (-f), je, že si mám hlídat tu druhou a říct jí, aby nesrala u sousedů (o to horší, že ta nehoda se stala náhodně a nečekaně, tj. rada že se na to mám předem připravit to dělá o to lepší). To je imho úplně naruby - když požaduju, aby bylo něco chráněno, tak to vyřeším přímo na té konkrétní věci (zamčený soubor), a ne na celém zbytku vesmíru.

Ale budiž. Já vidím, že vás nepřesvědčím. Ta příhoda je náhodný příklad BTW, ne že bych z toho měl trauma nebo obsesi, jak se mě asi snažíte naznačit.

[smazáno]

Jasne, nekdy je fakt potreba chranit a melo by to byt podporovano. Akorat ve vetsine pripadu to spis nastve, jak jsme vam ukazali na jinych pripadech - takze to vynucovat je pekna kravina.

[Michal Vyskočil]

Hele, chapu, ze te jednou vypekl x264 encoder, ale spravne reseni by bylo, aby se te zeptal jestli chces pokracovat, i kdyz soubor uz existuje (na to je v unix konvenci prepinac -f).

-f/--force obvykle znamená pravý opak :)

[Olda]

mě by stačilo, kdyby ve warcraftu 3 kurzor neměl tak šílené zpoždění... ZKoušel W3 spustit s opengl, bez něj. V registru jsem měnil lockfb... Pořád nic...

[XMen]

no a to si potom niekto moze vysvetlit ako nekvalitu linuxovych app oproti windowsovym. Ze si nemozem subor precitat lebo je uzavrety pre zapis by ma asi nastvalo. Ale ze mi nieco bez mojho vedomia (resp. uvedomenia) prepisuje subor tak to by som asi ten komp vyhodil von oknom. To co sa tu popisuje vyssie v prispevku ako niekomu jedna instancia prepise subor druhej je podla mna nekvalita programu, ktory si to ma osetrit alebo teda aspon uzamknut subor pre zapis.

[Bedňa]

Až budeš kvôli nekvalitným linuxovým aplikáciam vyhadzovať komp von oknom, zavolaj.

Poďalšie klikol si na úplne iné vlákno.

A posledný bod, boli to dve inštancie na MS Windows. Ty píšeš určite kvalitné programy.

[Ovocníček]

Ale to jejich chování je unixové, páč x264 se kompiluje MingWem a používá tu funkce přes něj, či co. Jednou jsem to nadhazoval na IRC a alespoň něco v tom smyslu mi bylo řečeno. /Zkrátka chyba je v tom, že unix je trošku jako amishové a civilizační výdobytky považuje za dekadenci :)/

[Bedňa]

Defaultne sa na Linuxe súbory nezamykajú, ale dávajú ostatatným aplikáciam vedieť že v súbore nastala zmena, to si stačí overiť otvorením toho istého súboru dva krát, alebo zapísať niečo do otvoreného súboru. Neviem ako to je teraz, ale prv toto Win nevedeli a preto si všetko zamykajú a ani USBflash nejde bezpečne odpojiť, keď je napríklad spustený prieskumník v USBpriečinku.

[tsLnox]

Ale to zrovna v Linuxu u umountu platí taky, ne?

[Jakub Lucký]

třeba pro Nautilus ne...

[XMen]

Uz som vyhodil, mal si tu byt tak pred rokom.

Som stale v tej iste diskusii ci nie? Hlavne, ze vy ste to pochopil a tak ste mohol reagovat.

To ale nic nemeni na realite, ze linuxove programy su z mojho hladiska menej kvalitne, dokonca aj ked ide o ten isty program, ktory ma klon pod windows.

Ano, ja sa snazim pisat kvalitne programy s ohladom na ergonomiu a bezpecnost. To je asi hlavny rozdiel medzi junior a senior programatorom.

[victor8]

Tak ja neviem, vzdy som bol v tom, ze za kvalitnejsi program sa povazuje ten, ktory je lepsie zaintegrovany do cielovej platformy, resp. lepsie dodrziava jej zazite konvencie a standardy.

Ak je v UNIXovom svete konvenciou ze mandatory locking sa standardne nepouziva, tak spravne (ako pises ty, seniorom) napisany program by ho (pokial to nie je nutnostou vyplyvajucou zo spefifickych poziadavok ulohy, ktoru riesi) vyzadovat/ocakavat nemal.

Alebo sa mylim?

[XMen]

Ano ale treba si uvedomit, ze kolko ludi co prechadza na unix pozna jeho konvencie resp. ci si ich vobec uvedomuje? Pokial viem tak snad vsetci co dnes robia s linuxom nan presli z windowsu. Alebo sa mylim?

[Bedňa]

Poprosím jediný dôkaz tvojho tvrdenia. Vsadím 100euro až ma presvedčíš namiesto mlátenia prázdnej slamy. Ja by som to za 100€ spravil!

[Bedňa]

Pokiaľ ten dôkaz nedáš, tak doživotne ti budem odpisovať, malej pindíku!

[Bedňa]

Poďalšie kliknúť na úplne ine iné vlákno to chce fakt kus inteligenta voe!

[XMen]

Tak mi este napis inteligente ake moje tvrdenie chces dokazat?

[Olda]

mě by stačilo, kdyby ve warcraftu 3 kurzor neměl tak šílené zpoždění... ZKoušel W3 spustit s opengl, bez něj. V registru jsem měnil lockfb... Pořád nic....

[jurasn]

Zkuste pohledat, jestli se nedá u war, stejně jako u WOW někde v nastavení vynutit použití hardwarového kurzoru. Jelikož je to napsané ve stejném enginu, mohlo by to pomoci.

[mankind_boost]

By mě fakt zajímalo, jak se jim podařilo, že hodnocení běhu některých aplikací se změnilo z platinum na garbage

[Vladimír Čunát]

Četl jsem že je to typicky chyba toho uživatele, třeba si nepřečetl jak hru instalovat pod wine a zkoušel to přímo jako ve windows...

Napovědět může i fakt, že u hodnocení od správců programů žádné výrazné poklesy obvykle nejsou.

[Jiří J.]

Tak tak, říkal jsem to už u několika minulých Zpravodajů, nejde jen o -4, ale často i třeba o -2 nebo -3. Tak třeba NFS: WC - autor "garbage" hodnocení podle všeho nečetl ani druhý post, který jasně říká, co dělat.

Prakticky se stává velmi zřídka, že by se zhoršila podpora pro nějakou hru / aplikaci. Mě se to stalo jen u SW: Jedi Academy, která mi na wine 1.1.x fungovala bez problémů a workaroundů, a na 1.3.x se mi ji nepodařilo rozjet. Na 1.5.x to podle všeho zase funguje.