Byl vydán Fedora Asahi Remix 40, tj. linuxová distribuce pro Apple Silicon vycházející z Fedora Linuxu 40.
Představena byla služba Raspberry Pi Connect usnadňující vzdálený grafický přístup k vašim Raspberry Pi z webového prohlížeče. Odkudkoli. Zdarma. Zatím v beta verzi. Detaily v dokumentaci.
Byla vydána verze R14.1.2 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Dnešním dnem lze již také v Česku nakupovat na Google Store (telefony a sluchátka Google Pixel).
Apple představil (keynote) iPad Pro s čipem Apple M4, předělaný iPad Air ve dvou velikostech a nový Apple Pencil Pro.
Richard Biener oznámil vydání verze 14.1 (14.1.0) kolekce kompilátorů pro různé programovací jazyky GCC (GNU Compiler Collection). Jedná se o první stabilní verzi řady 14. Přehled změn, nových vlastností a oprav a aktualizovaná dokumentace na stránkách projektu. Některé zdrojové kódy, které bylo možné přeložit s předchozími verzemi GCC, bude nutné upravit.
Free Software Foundation zveřejnila ocenění Free Software Awards za rok 2023. Vybráni byli Bruno Haible za dlouhodobé příspěvky a správu knihovny Gnulib, nováček Nick Logozzo za front-end Parabolic pro yt-dlp a tým Mission logiciels libres francouzského státu za nasazování svobodného softwaru do praxe.
Před 10 lety Microsoft dokončil akvizici divize mobilních telefonů společnosti Nokia a pod značkou Microsoft Mobile ji zanedlouho pohřbil.
Fedora 40 release party v Praze proběhne v pátek 17. května od 18:30 v prostorách společnosti Etnetera Core na adrese Jankovcova 1037/49, Praha 7. Součástí bude program kratších přednášek o novinkách ve Fedoře.
Stack Overflow se dohodl s OpenAI o zpřístupnění obsahu Stack Overflow pro vylepšení OpenAI AI modelů.
Řešení dotazu:
19.2.2013 00:03
Josef Kufner | skóre: 70
Podle nadpisu jsem původně otázku pochopil stejně, ale pak mi došlo, že tazatel se ptá na něco jiného. Myslím, že ho zajímá velikost grafické paměti hostitele.
Na grafické kartě hostitele naprosto nezáleží. Stačí cokoli podporovaného hostitelským OS a je naprosto jedno kolik virtuálních guestů poběží. Samozřejmě je třeba jednotlivým guestům přidělit dostatečné množství video RAM pro předpokládané rozlišení.
Ne. Grafika u hostitele nemá vůbec nic společného s grafikami guestů. Těm se prostě přiřadí virtuální grafická karta.
To jen tak, že to nemusí být jen 'bug' ale i 'feature'.Pokud software zavolá sync() a hypervizor nečeká na skutečné zapsání na disk, je to bug. (Teda pokud sis ho sám nenastavil, aby nečekal.)
Pokud je to disk VM, tak to rozhodně jako samozřejmost neberu natož aby to byl 'bug', z pohledu virtualizovaného systému se sync provede.Můžeš mít svůj náhled, ale to nemění nic na tom, že takové chování je bug. Operační systém hosta při sync zadává požadavek, aby mu bylo nahlášeno, že disková operace je bezpečně dokončená, tj. že jsou data zapsaná na úložišti. U virtualizovaného hardwaru mu tu informaci předává hypervizor a pokud ji předává dřív, než je to pravda, je to chybné chování. Důsledkem takového chování je pak to, že se s trvalým úložištěm nedá pracovat bezpečně - pro začátek kód filesystému vyžaduje dodržení pořadí diskových operací a falešné dokončení sync toto pořadí může snadno narušit.
To je jako se zápisem do RAID HW cache nebo třeba u hybridního hadru.To teda není. Pokud je to volatilní cache (RAM) a není zálohovaná baterkou, tak ti hw raid nenahlásí dokončení operace, dokud data nejsou na disku (opět - pokud si ho tak nenastavíš.)
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
xm sysrq vmid s jsem vždycky bral jen jako klasický sync VM.Důsledkem takového chování je pak to, že se s trvalým úložištěm nedá pracovat bezpečně - pro začátek kód filesystému vyžaduje dodržení pořadí diskových operací a falešné dokončení sync toto pořadí může snadno narušit.Jak by se mohlo to chování narušit, je to „jen“ soubor, v kterém je filesystém, a přístup k němu poskytuje virtualizační engine a ten se stará o správné chování (včetně pořadí či sync-u) a vůbec to nesouvisí s tím jestli byl nebo nebyl obsah tohoto souboru fyzicky zapsán na disk - to je de-facto pro VM už oblast hardware.
22.2.2013 16:31
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Jak by se mohlo to chování narušit, je to „jen“ soubor, v kterém je filesystém, a přístup k němu poskytuje virtualizační engine a ten se stará o správné chování (včetně pořadí či sync-u) a vůbec to nesouvisí s tím jestli byl nebo nebyl obsah tohoto souboru fyzicky zapsán na disk - to je de-facto pro VM už oblast hardware.Že by FS zůstal v nekonzistentní stavu, když hostitel sletí? Naprosto nechápu, jak s tím souvisí, jestli je FS v souboru, na LV nebo přímo na partition.
22.2.2013 17:07
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Ano, to ale zůstane i FS přímo na disku, když se „sletí HW“. Anebo co když sletí hostitel v momentě sync-u…Proto taky čekáš na výsledek syncu. A když ti přijde, uděláš nějakou ztrátovou operaci (zahodíš transakci z žurnálu, mailserver pošle protistraně „delivered to mailbox“, DB server zavře transakci…). Jenže když ti HW kecá, ztratíš data. A v případě, že HW zapsal operace v jiném pořadí, ale ne všechny (typicky žurnál + NCQ), rozbiješ si FS.
Ano, to ale zůstane i FS přímo na disku, když se „sletí HW“.Moderní FS a jejich drivery nemají s uříznutím v libovolném okamžiku problém. Maximálně pak znovu přehrajou žurnál.
Souvisí to s tím dost zásadně, pokud je to LV tak to pracuje přímo s LV a zodpovídá si za uložení dat sama VM a to přímo na zařízení vs. pokud je to „jen“ soubor o kterém VM nemá ani páru a o práci s tímto souborem se stará Virt. engine.Já teda ze svých VM (KVM a VirtualBox) ani nedokážu zjistit, jestli mám virtuální disk v souboru nebo na blokovém zařízení.
Nedokážu si představit, že mám virtualizovaný stroj (ne paravirtualizovaný) a v něm nahodím libovolný OS, který si pracuje „nějak“ s diskem (v souboru, o kterém neví), že by to mělo mít vliv na to jak se flushuje tento soubor v nadřazeném Virt. engine.To nemá vliv…
22.2.2013 17:43
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Jo to právě říkám - VM o tom nemá ani páru…Pak furt nechápu
Pokud je připojena fyzická partition nebo LV tak je to jiná, ale a tam zas do toho nevstupuje virtualizační engine.
22.2.2013 18:17
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Pokud VM pracuje přímo se zařízením, stará se o sync na zařízení sama bez prostředníkaO RLY? Já z VM vidím nějaký virtuální řadič a když mu pošlu sync, stejně to musí hypervizor přeložit. Ostatně co kdybych fejkoval a místo souboru přímo tomu dal soubor namapovaný na /dev/loop0?
takže zaručeně vím, že ve VMW dosáhnu výrazně rychlejších diskových operací s malým objemem datZa prvé - pokud při těch operacích nevyžaduješ zápis na disk, pak je to stejné jako na čistém železe. Soubor skončí v RAM a někdy se zapíše. Za druhé - to, že něco nějak dělá VMWare, ještě neznamená, že je to správně. VMWare je klasický komerční produkt, obchodníci potřebují ukazovat hezké tabulky a prezentace o tom, jak je to výkonné, takže programátoři se musí přizpůsobit. (Dost možná v tom dokonce půjde někde naklikat "vypnout bug".)
24.2.2013 17:50
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Za prvé, není, je to o kus rychlejší, „už“ se zápisy na disk realizují (už jen proto, že by pak virtuální RAM byla rychlejší než fyzická)…Parse error.
Za druhé, ano je to komerční soft a není to dle obchodních informací, ale dle zkušeností.Nepochopil. Ne, že by s rychlostí lhali, ale že musí dosahovat rychlosti na úkor bezpečnosti.
931.2 This kind of superficial resemblance and underlying divergence happens in other engineering contexts. I've a friend who was once a senior executive at a big consumer packaged goods company who told me about what happened when the marketing department told the engineers that they'd thought up a great idea for detergent: from now on, they were going to make detergent that made your clothes newer every time you washed them! Well after the engineers had tried unsuccessfully to convey the concept of “entropy” to the marketing department [audience laughs], they arrived at another solution – “solution” – they'd develop a detergent that used enzymes that attacked loose fiber ends, the kind that you get with broken fibers that make your clothes look old. So every time you washed your clothes in the detergent, they would look newer. But that was because the detergent was literally digesting your clothes! Using it would literally cause your clothes to dissolve in the washing machine! This was the opposite of making clothes newer; instead, you were artificially aging your clothes every time you washed them, and as the user, the more you deployed the “solution”, the more drastic your measures had to be to keep your clothes up to date – you actually had to go buy new clothes because the old ones fell apart.(--Cory Doctorow)
A ať je to jak chce, tak to neznamená, že to je správně nebo nesprávněPokud ti to zničí databázový cluster nebo ztratí maily, tak to asi bude nesprávně.
- je to otázka garancí - a ty nevím jaké jsou, nikdy mě to nezajímalo.Společnost VMWare negarantuje, že soubory, o kterých vám řekneme, že se zapsaly na disk, na disku skutečně budou.
NepochopilNepochopil. Mé tvrzení je na základě zkušenosti a nevím, že by něco takového VMWare prezentovalo, pokud vím tak, ne u VMW, ale u „serverových řešení“ prezentují, že dosahují téměř rychlostí fyzických zařízení.
Pokud ti to zničí databázový cluster nebo ztratí maily, tak to asi bude nesprávně.A nic jiného si nezasloužíš, když na to VMWare Workstation použiješ pro ostrý provoz.
Společnost VMWare negarantuje, že soubory, o kterých vám řekneme, že se zapsaly na disk, na disku skutečně budou.To negarantuje žádný dodavatel/tvůrce SW. A pokud se garancí týče, mám namysli prezentované chování konkrétním SW, tedy VMW, nevím jak je popsána přesně funkce (každopádně lze vybírat různé typy disků/řadičů, a při nastavení kompatibility ze serverovými řešeními se možnosti omezí).
24.2.2013 19:59
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Poznámka k závorce: Narážka na to, že kdyby tomu tak nebylo, a zápisy by se realizovaly jen do cache a bylo by to stále rychlejší ve VM, tak by z toho plynulo (nebo my mohlo), že RAM ve VM je rychlejší než v hostiteli.Nevidím tam toto plynutí, ale možná pořád nechápu, co tím chceš říct. Proč není jedno, jestli na zápis na disk nečeká hypervizor nebo samotný OS?
To negarantuje žádný dodavatel/tvůrce SW.Dobře, ale pokud úmyslně způsobuje vyplnění své negarance, je to na pováženou.
ten virtuální disk se pro VM chová naprosto korektněNechová. Disk, který prohlásí, že zapsal nějaká data, a ta data tam po resetu nejsou, se prostě korektně nechová.
to, že se fyzicky nezapsaly na disk je z pohledu VM jen chyba HWPak tedy VMWare dodává vadný HW.
Nevidím tam toto plynutí, ale možná pořád nechápu, co tím chceš říct. Proč není jedno, jestli na zápis na disk nečeká hypervizor nebo samotný OS?Je to jedno…, ale pokud by systémy (ve VM a na fyzickém stroji) měli stejné podmínky a zapisovala by se data „jen“ do cache a ve VM by tento zápis byl rychlejší, tak by to znamenalo, že VM by měla rychlejší cache a cache je RAM, tedy by ve VM byla RAM rychlejší. (V té poznámce k závorce, by na konci mělo být na fyzickém HW, to v hostiteli je matoucí.)
Dobře, ale pokud úmyslně způsobuje vyplnění své negarance, je to na pováženou.Na pováženou by bylo, kdyby deklaroval, že data zapsaná do virt. disku jsou zapsaná ihned i na fyzický a ona tam nebyla, takto v tom nevidím žádný problém (opět: nevím, co je „deklarováno“).
Nechová. Disk, který prohlásí, že zapsal nějaká data, a ta data tam po resetu nejsou, se prostě korektně nechová.Jak v /dev/ramX tak i v /dev/shm tam ta data po reset-u také nejsou.
Pak tedy VMWare dodává vadný HW.Pokud dojde k chybě ve VMW a „spadne“ (což je možné, ale pro mě neznámé ;)), tak ano, je to chyba vadného virt. HW, ale jinak „ne“, zklamalo totiž to, o co se virtuální HW opírá, tedy něco mimo jeho kontrolu.
Na pováženou by bylo, kdyby deklaroval, že data zapsaná do virt. disku jsou zapsaná ihned i na fyzický a ona tam nebyla, takto v tom nevidím žádný problém (opět: nevím, co je „deklarováno“).U hardwaru, který se má chovat jako řadič disku a disk, je deklarováno, že když řadič oznámí, že data byla zapsána na disk, tak skutečně byla zapsána na disk (nebo přinejmenším někam, odkud se neztratí, tj. např. RAM zálohovaná baterií.) Pokud VMWare nahlásí operačnímu systému virtuálního serveru dokončení operace ve chvíli, kdy to není pravda, je to chyba, protože jeho virtuální hardware se nechová podle očekávání.
Jak v /dev/ramX tak i v /dev/shm tam ta data po reset-u také nejsou.Jenže od /dev/ram nikdo nic takového neočekává. Od disku, tedy nonvolatilního úložiště, ano.
U hardwaru, který se má chovat jako řadič disku a disk, je deklarováno, že když řadič oznámí, že data byla zapsána na disk, tak skutečně byla……a ona tam skutečně jsou (v tom virtuálním disku) - tedy chování správné.
…kdy to není pravda…ona to je pravda…
Jenže od /dev/ram nikdo nic takového neočekává. Od disku, tedy nonvolatilního úložiště, ano.S tím „nikdo“ opatrně :), „očekávání“ je cesta do pekel, prostě cokoliv má nějaké vlastnosti a podle toho je se k tomu potřeba chovat.
…a ona tam skutečně jsou (v tom virtuálním disku) - tedy chování správné.ok, tak jinak: že tam skutečně jsou a že tam budou i v případě havárie napájení.
Pokud sletí fyzický HW dokud se neprovede fyzický zápis a ta data nebudou na fyzickém disku, prostě selhala bateriem je to „jen“ virtuální disk.Nic jako "jen" virtuální disk neexistuje. Z pohledu operačního systému hosta je to disk jako každý jiný a tak se taky má chovat.
ok, tak jinak: že tam skutečně jsou a že tam budou i v případě havárie napájení.Tak taky jinak, pokud se pokazí disk, tak na něm data jsou - nejsou…
Nic jako "jen" virtuální disk neexistuje. Z pohledu operačního systému hosta je to disk jako každý jiný a tak se taky má chovat.To je potom jasné, že se nemůžeme shodnout.
/dev/loopX.Tak taky jinak, pokud se pokazí disk, tak na něm data jsou - nejsou…Omyl. Pokud se pokazí disk, je pokažený a data tam nejsou žádná (nejdou číst). Pokud se nahlásí falešný zápis, po restartu se ten disk chová jako by se nic nestalo.
virtuální disk existuje a nevymyslel jsem si jej a používám je už 300 let.To, že nějaké vmwarovské klikátko něco nazývá "virtuální disk", ještě neznamená, že se chová korektně, když hostovi neposkytuje to, co má dělat skutečný disk.
Omyl. Pokud se pokazí disk, je pokažený a data tam nejsou žádná (nejdou číst). Pokud se nahlásí falešný zápis, po restartu se ten disk chová jako by se nic nestalo.Co na to říct…, třeba: „ne vždy“. Z druhé části nejsem moudrý…
To, že nějaké vmwarovské klikátko něco nazývá "virtuální disk", ještě neznamená, že se chová korektně, když hostovi neposkytuje to, co má dělat skutečný disk.To že nějaký sw nemá funkcionalitu „virtuálních disků“, ještě neznamená, že jiný je mít nemůže a že se virt. disky nemohou chovat korektně jako virtuální disky a mohou poskytovat hostovi, přesně tu stejnou funkcionalitu jako fyzické disky.
Co na to říct…, třeba: „ne vždy“. Z druhé části nejsem moudrý…Ze svých zkušeností můžu říct, že když disk odejde, tak se to rozhodně pozná. Když na tom stroji není raid, tak prostě spadne a nenabootuje, když tam je, tak jádro disk vyhodí z pole. A ve většině případů pak ten disk neodpovídá ani na dotazy na data ze S.M.A.R.T., na tož aby se pak šlo dostat k nějakým datům. A v tomhle případě na tom ani nesejde. Pro tuhle diskuzi je důležité, co se stane, když na ten disk zapíšu data, žádám o informaci, že zápis byl dokončen, a těsně poté vypadne proud. U normálního fyzického a korektně se chovajícího disku zapíšu soubor, vyžádám si od jádra potvrzení zapsání, jádro si vyžadá od disku potvrzení zápisů, které se zápisem souboru souvisí; když ho dostane, předá mi informaci o tom, že soubor byl zapsán. V takovém případě vím, že v případě výpadku napájení tam po restartu ten soubor bude. Totéž platí pro korektně se chovající disk ve virtuálním serveru. U tvého hyper-super-mega-vmware disku si vyžádám potvrzení zápisu souboru, jádro si vyžádá potvrzení od disku, dostane ho, potvrdí mi zápis souboru, ale po výpadku napájení tam ten soubor nebude. To je ztráta dat způsobená nekorektním chováním hardwaru, který se ale před i potom tváří, že funguje naprosto v pořádku. Jaké to má důsledky jsem ti tady víckrát popsal nejenom já.
To že nějaký sw nemá funkcionalitu „virtuálních disků“, ještě neznamená, že jiný je mít nemůžeS touhle narážkou jsi úplně mimo.
a že se virt. disky nemohou chovat korektně jako virtuální disky a mohou poskytovat hostovi, přesně tu stejnou funkcionalitu jako fyzické disky."virtuální disk" je jenom název, nic víc. Když se odkážu na ty hezké obrázky, cos poslal, klidně by se mohl jmenovat "souborový disk". Podstatné není, jak se to zařízení jmenuje, ale jak se chová. A ano, klidně se z pohledu hosta může chovat stejně fyzický disk. Jenže celá tahle debata je o tom, že ten disk se tak pod VMWare nechová
A já se ptám: „má to smysl pokračovat?“No pokud nejsi ochoten akceptovat fakt, že disk, který hlásí dokončení operace, aniž by ve skutečnosti byla dokončena, se chová nekorektně, tak ne. Akorát bych ti s takovým přístupem doporučil, abys nikdy nikomu nenabízel, že mu uděláš virtuální server. A nebo si nediv, až tě pošle tam, kam ti slunce nesvítí.
chová se jako virtuální disk a snažil jsem se ti popsat důvody, proč si myslím, že se to je ok.Tak ještě jednou: z pohledu operačního systému hosta nic jako virtuální disk neexistuje. Pro něj je to prostě disk. Disk se má chovat podle nějakých specifikací a že se tak bude chovat, za to je zodpovědný jeho výrobce, zde VMware. Pokud se tak nechová (kromě případů, kdy jsem mu explicitně řekl, že nemusí), je to chyba.
Tak ještě jednou: z pohledu operačního systému hosta nic jako virtuální disk neexistuje…To je zásadní, tak to musí být, guest to tak musí vidět.
Disk se má chovat podle nějakých specifikací…Tak ještě jednou (a už naposledy, bo se motáme v kruhu): on se tak chová.
Tak ještě jednou (a už naposledy, bo se motáme v kruhu): on se tak chová.Ano, ale pouze pokud - podle tvého tvrzení - najdeš a odškrtneš nějaké zaškrtávátko. To je špatně.
Chyba to není, chybou je „předpokládat“…Tohle je blábol. Pro hardware existují nějaké specifikace a ten hardware je má splňovat. Pokud je nesplňuje, nechová se korektně. Nebo je snad chyba předpokládat, že procesor, který hlásí podporu SSE, bude umět vykonat SSE instrukce?
Ano, ale pouze pokud - podle tvého tvrzení - najdeš a odškrtneš nějaké zaškrtávátko. To je špatně.Je to tedy tak, že ti vadí default (a možná ještě zaškrtávátko). To že je to pro Tebe špatná volba ok - smiř se s tím ;), pro mě je dobrá. Ale obecně to prostě špatně není(, protože je to popsané).
Tohle je blábol. Pro hardware existují nějaké specifikace a ten hardware je má splňovat.Ano a pokud je nesplňuje, tak je to chyba, k tomu zde, ale naprosto jasně nedochází.
Nebo je snad chyba předpokládat, že procesor, který hlásí podporu SSE, bude umět vykonat SSE instrukce?To není chyba, to je jasná specifikace/informace. Ale chybou by bylo předpokládat, že virtualizovaný procesor má automaticky podporu SSE když běží na HW, který ji má (myslím virtuální/emulovaný procesor, ne procesor podporující virtualizační technologie).
27.2.2013 12:58
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Ale obecně to prostě špatně není(, protože je to popsané).
~/git/project> grep -A 4 rm README Implicit Makefile is doing rm -rf on your ~ when you run "make" and on your /usr when you run "make install" as root. To disable this feature, set PRESERVE_HOME and PRESERVE_USR variables to YES.O RLY?
.vidím ho v tom, že 'Virtual disk' není identický s 'HDD'Virtuální disk je smyšlený koncept autorů vmware, obecně je to úplně to samé jako disk nebo LV - hromada po sobě jdoucích bajtů. Není důvod, aby se to chovalo jinak podle toho, na který radiobutton si klikneš.
Virtuální disk je smyšlený koncept autorů vmware, obecně je to úplně to samé jako disk nebo LV - hromada po sobě jdoucích bajtů.To je tvůj výklad, již bez komentáře.
Není důvod, aby se to chovalo jinak podle toho, na který radiobutton si klikneš.Podívám-li se zevnitř, chová se naprosto identicky - tedy to odpovídá, ale pokud se dívám z venku, tak bych opravdu to takto nechtěl, bylo by to dost omezující a jak u KVM tak VMWare Work. toho umí víc, takže ten důvod je - minimálně (asi) 'unsafe' či 'Independent nonpersistent' nelze navodit na fyzickém HDD.
27.2.2013 18:14
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Podívám-li se zevnitř, chová se naprosto identicky(vadně)
jak u KVM tak VMWare Work. toho umí vícCo třeba?
takže ten důvod je - minimálně (asi) 'unsafe' či 'Independent nonpersistent' nelze navodit na fyzickém HDDProč? Prostě vypneš čekání na potvrzování zápisu.
27.2.2013 18:04
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Na větu bez kontextu je to dobrá odpověďNevidím tam kontext, který by to měnil. Vidím tam jenom myšlenkový pochod
27.2.2013 18:38
Jendа | skóre: 78
| blog: Jenda
| JO70FB
když vytvářím virtuální disk nemůžu automaticky předpokládat, že se chová jako (většina) HDD, protože to není totéžKdyž spustím KVM (s VMWare neumím) a dám mu prostě jako disk LV nebo dokonce fyzický disk, kam se poděla ta virtuálnost?
to chování žádná data neničíBylo ukázáno, jak to v tichosti zahodí maily a nikdo se nic nedozví.
Když spustím KVM (s VMWare neumím) a dám mu prostě jako disk LV nebo dokonce fyzický disk, kam se poděla ta virtuálnost?To máme pak připojeno blokové zařízení - to není už virtuální disk. V tomto případě jsme oprávněni předpokládat, že se bude chovat přesně tak, jako toto zařízení - o tom žádná.
Bylo ukázáno, jak to v tichosti zahodí maily a nikdo se nic nedozví.Jen je nezapíše, nezničí je, ale když to tak chceme, a nastavili jsme si to, tak s tím musíme počítat.
27.2.2013 19:09
Jendа | skóre: 78
| blog: Jenda
| JO70FB
To máme pak připojeno blokové zařízení - to není už virtuální disk. V tomto případě jsme oprávněni předpokládat, že se bude chovat přesně tak, jako toto zařízení - o tom žádná.A když mu dám soubor namapovaný na /dev/loop? A proč u obyčejného souboru se ten fsync nezavolá, ale u blockdev jo? Pro hypervizor je to úplně stejné volání jádra a nerozlišuje mezi tím.
Jen je nezapíše, nezničí jeOdesílatel vidí, že je mailserver přijal, příjemce je ve schránce nemá. Nezapíše, zahodí.
Odesílatel vidí, že je mailserver přijal, příjemce je ve schránce nemá. Nezapíše, zahodí.Nebudeme to ladit, ano výsledkem je neexistence mailu v mailboxovém masivu.
Pochod jde správným směrem na nesprávné cestě, když vytvářím virtuální disk nemůžu automaticky předpokládat, že se chová jako (většina) HDDJeště jednou, protože ti tahle část zjevně uniká: z pohledu virtuálního serveru nemůžeš rozlišit, který radiobutton se zaškrtnul a jestli vůbec nějaký radiobutton existuje (protože jak vůbec víš, že jsi ve virtuálním serveru?) Proto se disk prezentovaný tomu virtuálnímu serveru musí ve výchozím nastavení chovat jako normální disk, protože tak to vyžaduje specifikace pro disk. Pokud se tak ve výchozím nastavení nechová, je to chyba, protože výchozí chování je nebezpečené a potenciálně může vést k destrukci dat. Na tom nic nemění to, jak si kdo pojmenuje nějaký radiobutton.
27.2.2013 18:06
Jendа | skóre: 78
| blog: Jenda
| JO70FB
(, byť tam nemůžu najít ten pozitivní efekt)Uvolnění místa na disku.
To není chyba, to je jasná specifikace/informace.A stejně tak je jasná specifikace toho, jak se má chovat disk.
Příští týden dostaneš do ruky HDD (či black box RAID), který bude mít aktivní cache bez baterie a bude v režimu write-back, ty pak přijdeš o data a budeš se hájit, že je to chyba HWNedávno jsem dostal do ruky "blackbox RAID", který si při spuštění stroje dost jasně stěžoval, že nemá záložní baterii a že všechny pole nakonfigurované na writeback se přepínají do writethrough, dokud tam ta baterie nebude. A opět - pokud by to výrobce udělal jinak, je to chyba, protože výchozí chování je nebezpečné.
…je to chyba, protože výchozí chování je nebezpečné.Hm.
writethrough a podporuje další tři „nesprávné“ ;) režimy (writeback, none, unsafe).Ano, výchozí hodnota je bezpečná, což je podle mě docela zásadní.A podle mě je zásadní vědět, co je nastavené a jaké to má důsledky (pokud mají nějaký dopad, který mě/někoho zajímá).
A nevím, co tě vedlo k tomu, nazvat režim cache=none jako "nesprávný".?
scsi0:0.writeThrough = "TRUE".
22.2.2013 16:33
Jendа | skóre: 78
| blog: Jenda
| JO70FB
22.2.2013 17:01
Jendа | skóre: 78
| blog: Jenda
| JO70FB
22.2.2013 17:19
Jendа | skóre: 78
| blog: Jenda
| JO70FB
a když se po..re, tak je to prostě rozbité…Ale my tomuhle umíme předcházet! Bohužel bug v HW (ať už fyzickém nebo virtuálním) tomuto zabraňuje.
.tak se „maximálně“ přijde o nezapsané data.No jasně, někomu to třeba nevadí, ale třeba u relační DB, která nějak komunikuje s okolním světem, by to mohl být trochu problém.
Tiskni
Sdílej:
