Dual-boot esetén érdemes letiltani a Windows 8 "Fast Startup" funkcióját

Fájlrendszer, NAS, storage

A H Open arról ír, hogy ha valaki Windows 8 mellett Linux (vagy más) rendszert is tart számítógépén és Linuxról (vagy más rendszerről) szokta írni a Windows NTFS partícióit, akkor ajánlott kikapcsolni a Windows 8-ban alapértelmezetten bekapcsolt "Fast Startup" funkciót, elkerülendő, hogy az írt fájlrendszer inkonzisztens állapotba kerüljön, vagy rossz esetben adatvesztés lépjen fel. A jelenség nem új, de a Windows 8 Fast Startup funkciója miatt sokkal valószínűbb, hogy előjön, mivel a korábbiaknál több ember fog anélkül hibernálni, hogy valójában tudná, hogy azt teszi. Az ntfs-3g fejlesztői már gondoskodtak a probléma megfelelő kezeléséről. A megfelelő változtatásoknak köszönhetően a driver csak "read-only" módba mountolja a Windows partíciót, ha észleli, hogy a Fast Startup funkció aktív. Viszont az ntfs-3g-ből egy éve nem jött ki új verzió, így a népszerű Linux disztribútorok se kínálják még széles körben az új driver-t... A részletek itt olvashatók.

( Finder | 2013. 01. 13., v – 18:14 )

Nem is ertem, hogy hibernation eseten miert nem uriti a rendszer a cache-eket. Nekem ugy tunik, hogy hatalmas pazarlas kiirni a vinyora valamit ami eleve onnan szarmazik, hogy aztan beolvassuk es talan egyszer hasznaljuk is.

Nem is ertem, hogy hibernation eseten miert nem uriti a rendszer a cache-eket

Milyen cache-re gondolsz? S4-nél még RAM context sem marad meg.

hatalmas pazarlas kiirni a vinyora valamit ami eleve onnan szarmazik, hogy aztan beolvassuk es talan egyszer hasznaljuk is

A "talán" itt nem "talán", hanem "következő boot-nál garantáltan", ui. a kernel session-t menti:

http://blogs.msdn.com/b/b8/archive/2011/09/08/delivering-fast-boot-time…

Now here’s the key difference for Windows 8: as in Windows 7, we close the user sessions, but instead of closing the kernel session, we hibernate it. Compared to a full hibernate, which includes a lot of memory pages in use by apps, session 0 hibernation data is much smaller, which takes substantially less time to write to disk. If you’re not familiar with hibernation, we’re effectively saving the system state and memory contents to a file on disk (hiberfil.sys) and then reading that back in on resume and restoring contents back to memory. Using this technique with boot gives us a significant advantage for boot times, since reading the hiberfile in and reinitializing drivers is much faster on most systems (30-70% faster on most systems we’ve tested).

Egy (másik) példa, ahol ez kellemetlen lehet: virtuális gépek copy-on-write diszkjeinél. A kernel session mentése simán felzabálhat 250-300 MB helyet (4G RAM alatt nem gondolom, hogy bárki is indítana win8 VM-et):

and in the case of our fast startup usage, it’s typically ~10-15% of physical RAM but varies based on drivers, services, and other factors

Az eredeti angol cikkben azt irjak, hogy a gondot az okozza, hogy a hibernalaskor nem vesznek el a lemez cache-ek. Tehat ha kozben modosul valami, akkor a hibernalasbol visszatero rendszer cache-eiben hibas adat lesz. Erre mondom, hogy eleve uriteni kene ezeket a cache-eket, sot az egesz kotetet unmountolni vagy legalabbis megjelolni, hogy minden adatot ellenorizni kell mielott hasznaljuk. Felesleges a cache-eket is a hibernalasnal a lemezre menteni, mert eleve onnan szarmaznak.

Nem én akartam erre reagálni, mert nem ismerem kellő részleteiben a fájlrendszerek lelki világát. De a file cache hibernálása annyira indokolatlan, hogy biztos vagyok benne, hogy az ürítésre kerül hibernálás előtt. Viszont tudok mondani legalább egy okot, amiért a fájlrendszer unmountolására nincs lehetőség: nyitott file handle-ök. Hibernáláskor (még ha az összes user process kilövésre is kerül), maradnak ilyen handle-ök, ha ezután valaki belepiszkál az fs-be (nem is kell feltétlenül a nyitott fájlokba), az biztosan gondot fog okozni a felébredő rendszeren.

igen, ez nekem is eszembe jutott. Egy megoldást tudok: hibernálás utáni felébredéskor ellenőrizni kell az összes file handle-t, hogy létezik-e az erőforrás még, és ha nem akkor zombi állapotba rakni. így nagy az esély rá hogy csak kifagynak az alkalmazások, de nem sérül meg a fájl.

( elod v | 2013. 01. 13., v – 18:46 )

Köszi, egyre érdekesebb ez a "fast startup".

Az ünnepek alatt rájöttem, hogy miatta nem megy a WOL sem, de még nem kapcsoltam ki...

Ha még kijön egy nyűgje, lehet, hogy lelövöm :D. A Fast Startup-ot, mert a Win8 marad.

( taxy | 2013. 01. 13., v – 19:01 )

"mivel a korábbiaknál több ember fog anélkül hibernálni, hogy valójában tudná, hogy azt teszi."

És milyen igazuk van:
http://hup.hu/node/119316
Idézett onnan:
"kevés linux használó tudja, hogy mi az, és hogy tud rendesen is működni. :D"

A mostani poszt által felvetett problémának mi köze van ahhoz, hogy a Linux-júzerek mennyire ismerik a Win8 fast boot funkcióját? Ha jobban ismernék, mint akár a legtrükkösebb MS-szoftvermérnök, akkor is hibák lesznek. Ez ugyanis dual-boot szempontból nem különbözik attól, mint amikor rosszul (egy erőteljes és kitartó power gomb megnyomásával) döntünk amellett, hogy a Windows helyett a Linuxot bootoljuk.
De fel lehet vetni a problémát másképp is: rengeteg Windows user használja Win-Win dual-bootban a gépét. Ilyenkor vajon mit segíthet, hogy mennyi Linux júzer mit tud erről a problémáról?
Vagy harmadik szempontként: szerinted egy r=1 Linux júzer hogy oldhatja meg ezt a problémát? Tehát fast boot-ra állított Win8-ról átbootol Linuxra, és ha a Win partíciókat írja, a Win-be való újrabootolás után ott nem jelentkezik semmi hiba?

Avagy ez nem trollkodás, csak az asztal billegésmentesítése? ;)

________________________________________
"The vision of Christ that thou dost see
Is my vision’s greatest enemy."

Szerintem a win-win felálllásban nincs gond. Mégpedig azért, mert a dual bootot úgy oldották meg, hogy először betöltenek egy fél Win8-at, aztán kérdezik meg, hogy tulajdonképpen te melyik rendszert is akarod. Ha a régit, akkor egy teljes reboot következik egészen a BIOS-tól. Gondolom, ilyenkor nem fastbootos leállítást követ el a rendszer maga ellen.

"kevés linux használó tudja, hogy mi az, és hogy tud rendesen is működni. :D"

Azt hittem lehet érezni a hangsúlyt. Vagyis az eredeti helyén arra vonatkozik az állítás, hogy linux-on olyan vacak a hibernálás, hogy szemben a windows felhasználókkal nem is tudjuk, hogy normálisan is tud működni.

Tehát ő azt állítja hogy windows-on jól működik, és ezt el is ismertem a hivatkozott helyen. Biztos így van. Ezt az idézetet igazából csak viccnek szántam, bár minden viccnek fele igaz. Hiszen fent írták, hogy nem egészen normális, hogy a fájlrendszer cache-t is eltárolja a hibernáló fájl. De trollkodásnak semmiképp nem működik, mivel fogalmam sincs hogy a linux is így hibernál-e vagy sem. Csak vicc. Oké? Mint ahogy az asztal láb is az akart lenni, csak kevésbé vicces.(szerintem)

Nahh azért az sem fenékig tejfel, én windowson is látok rendszeresen olyat, hogy pl. nem jön vissza szundiból...
A legérdekesebb pl. az, hogy szundiban lévő gépről lehúzol monitort (lehet az laptop vagy asztali több monitorral), utána visszajön, működik is rendesen, látja hogy nincs másik monitor, felbontást, monitor kiosztást stb vált, megy... Egészen míg újra nem indítod, ugyanis soha többet nem bootol fel utána. Kék halál normál és csökkentett módba is, nem lehet sehogy elindítani. Először én is hülyének néztem a usert, hogy ilyet még nem láttam, de aztán egy asztali gép után jött egy laptop, majd ezután megint egy asztali gép, más userektől dettó ugyanezzel a hibaleírással és jelenséggel. Az egyetlen közös dolog a win7 és a csodás ati vga+driver, szóval valamelyik marhára bugos. Én inkább az utóbbira tippelek.
A hibakódra rákeresve semmi konkrátumot adó dolgot nem találtam a googliban (win32k.sys hiba, vegyem ki az új hardvert ha tettem be, stb).
--
The Community ENTerprise Operating System

Hát ez tényleg hihetetlen. Még mindig ott tartunk, hogy a PNP megjegyez dolgokat, és nem lehet visszaállítani. De hogy a Csökkentett mód sem segít...

Viszont, még mindig ott van a visszaállító parancssor. Szépen megnézed a panaszos program beállításait. Hogy micsodát?

( gergov | 2013. 01. 13., v – 19:55 )

-
A kérdésemre ott a válasz a linkelt cikkben.

( eter | 2013. 01. 13., v – 20:13 )

vettem egy microsoft surface pro-t, de még mindig billeg az asztal lába

Éter @ Dragonfly BSD

( hunti v | 2013. 01. 14., h – 00:25 )

Jó tudni, egyszer már jártam így évekkel ezelőtt, amikor ubuntu/xp között váltogattam hibernálgatással, nem volt kellemes amikor kb 1 hónap után rájöttem hogy a korábbi munkám, és azóta létrehozott fájlaim nagy része semmivé vált. De legalább egy előnye volt a dolognak, rászoktam a rendszeres mentésre külső hordozóra..

( csabka v | 2013. 01. 14., h – 17:19 )

Off:
Mi van a VIII. kerületi számítástechnikai bolt ablakába?
Windows 8.

(lehet hogy szar, de legalább az enyém... most találtam ki :-) )