Linux - Win frågor

[MiaM]

Gäller väl i alla lägen om en OS är i sov eller hibernation och ett annan OS rotar på disken och man sedan går ur sov/hibernation igen för den första OS:t så vet inte OS om att det har rotats i filsystemet eftersom dess interna filtabeller i cache-minnen och andra platser inte uppdaterats eller läser in filsystemet igen och uppdaterar sig och det kan bli seriöst fel.

I hur stor utsträckning har OS'en nån slags skydd mot detta?

Man kan väl tänka sig att de med fördel synkar ut så mycket som möjligt av filsystemet och markerar så mycket cache å sånt som möjligt som ogiltligt. Ja, alternativt att checksumma saker där det bör märkas om "någon utomstående" micklat...

[xxargs]

Tror ingen OS eller filsystem har skydd för detta idag då mycket live-data hålls i RAM-minne och det synkas kanske var 30 sekund eller så av effektivitetsskäl (detta gäller både linux och windows, även om man i linux kan slå av detta eller ändra parametrar, i windows fuskar man dessutom med sin journalskrivning och committar saker innan det är helt färdigskrivna i jakten på prestanda etc. ...). till detta måste OS förstå att den måste städa ut så mycket den kan i avseende filpekare när den går i sleepläge/hib. och måste läsa in filsystemet från scratch igen när den väcks upp igen från sleep/hib-läge och att gamla öppna filpekare den hade på gång när den gick i sleepläge, kanske inte är aktuella längre.

Skall man göra något sådant så krävs det nya filsystem som är anpassade för driftfallet samt resp. OS är noga med sin hantering av denna filsystem och läser in dess status precis innan varje förändring och utan misstag i något läge - precis dom saker som de som optimerar prestanda vill pilla med lokala cache då en omläsning av filsystemets status vid varje operation är tidsödande sak... och är inte cachen global där _alla_ OS tittar i och uppdaterar så har man snart en trasig filsystem...

På SCSI-disk tiden så kunde man teoretiskt ha flera datorer på samma SCSI-bus och därmed åtkomst av samma diskar från flera datorer samtidigt, men jag har aldrig sett det realiseras i verkligheten och det beror nog mycket på svårigheten på att administrera samma disk/filsystem med flera oberoende aktörer samtidigt för risken att filsystemet blir inkonsistent. Kort sagt behöver man en monitorsystem [1] och denna kan då inte gå i någon 'sleepläge' - i princip alla OS har en egen monitorsystem för sin filhantering och ingen av dessa räknar med att det finns en annan 'dörr' med en annan OS med sin 'monitor' som rotar i samma lager samtidigt och bara uppdaterar förändringar i sin egen 'papperslapp' och det tar tid innan det blir globalt publicerat i filsystemet som ändå ingen läser eftersom alla tog sin kopia vid uppstart och dödräknar alla förändringar därifrån med då och då uppdatering mot filsystemet och utan att läsa tillbaka igen i tron att man ensamt sköter filsystemet själv och inget ändrar av sig själv i filsystemet.

När man har den nivån att flera olika OS/system faktiskt frågar mot samma filsystem så brukar lösningen kallas databasmotor och databas eller en filserver och då har man en 'monitorfunktion' där databasmotorn resp. filserverns OS är 'monitorn' och ansvarar för konsistensen i filsystemet - inte de olika OS och tjänster som frågar och skriver data.



[1] läs den sura lagergubben bakom luckan i dörren till lagret som kräver rekvisition för varenda pinal man vill ha ut, om man skall ha fortsatt ordning på lagret - var gång man tar bort den 'rollen'/luckan i någon form av besparingsiver och alla kan gå in i lagret och plocka det man vill, så brukar det nästan alltid sluta med total lagerhaveri efter ett tag eftersom inte alla bokför uttagen som de skall eller räknar på lagernivåer eller beställer och fyller på vid brister... )

[Josasp]

NTFS fungerar på nästan alla plattformar mha NTFS-3G eller liknande projekt.
Det enda egentliga problemet med NTFS-3G är att det alltid kommer vara experimentellt då man inte har byggt det efter spec.

Montera felaktigt avstängda diskar brukar man inte tillåta, då du kan behöva köra en CHKDSK från Windows.
Det kan man inte göra på Linux pga att man inte har stöd för det då NTFS inte är en öppen standard.

Inga problem att montera ändå mha terminalkommando, bara att forca en mount så går det.
Men om man verkligen behöver köra en CHKDSK på disken men force mountar så kan man förstöra innehållet.

[Glenn]

Jag har iofs nåt minne av att jag sett i sysloggen när man mountat nån NTFS-disk att det har körts nån chkdisk-motsvarighet.

..Nu brukar jag iofs säallan montera NTFS-diskar i linux, men det har ju hänt.

[kimmen]

tidigare använde Ubuntu 13.10 komprimerad på hårddisken och kunde utan problem läsa och skriva

Så vad var det då att det fungerade klanderfritt enligt ovan men inte med 'modernare' Linux dist?

Kan det vara så att den gamla versionen felaktigt tillåter att du monterar filsystem utan att de är korrekt avmonterade från ett Windows som är i hibernation, och att det är fixat i den nya versionen så att den inte längre tillåter den operationen som skulle kunna leda till katastrofal dataförlust?

[Josasp]

Jag har iofs nåt minne av att jag sett i sysloggen när man mountat nån NTFS-disk att det har körts nån chkdisk-motsvarighet.

..Nu brukar jag iofs säallan montera NTFS-diskar i linux, men det har ju hänt.

Det ska finnas någon fix-grej för NTFS på linux, men det har då aldrig löst något problem för mig.
CHKDSK har då räddat många Windows-installationer, där har inte linux-grejen hittat något alls.

Försökt många gånger när bara Live-Linux diskar funnits att tillgå, men har alltid fått skaffa mig en Windows-disk/sticka

[xxargs]

Det fins en 'grundbult' i form av 2 sektorer i NTFS, en ordinarie i början av volymen ($MFT) och en inkomplett kopia i ungefär mitten av volymen ($MFT_BAK) som om dessa går sönder så krachar filsystemet fullständigt och blir det ett helvete att försöka rädda ut filer ur disken även med kommersiella diskräddningsprogram - själva fil-kropparna kan oftast hittas men har tappat både filnamn och hieraki i filträdet och får bara ett nummer tillsamman med en miljon andra filer i samma platta directory, som även inkluderar raderade filer (som kan vara partiellt överskrivna med annat) och olika versioner av samma fil utan möjlighet att veta vilket som är vilket eller om den är komplett och ej överskriven partiellt...

Dessa två sektorer är ingången till hela filsystemet och är denna korrupt så vet inte OS var den skall börja leta eftersom sektorn ifråga också bär roten på filsystemet med plats för kanske 5-10 filer/directory och däri pekare mot viktiga filer och journaler som annars hade kunna hjälpt vid en restaurering. NTFS har bara en enkelänkad lista från roten ut mot grenarna på sann engelsk managementstil vilket gör att det går inte bygga filsystemet från grenarna in mot roten om roten skulle skadas...

Har man tur så är det någon gren i filträdet som klarar sig och man får fatt på den underliggande strukturen - men den filgrenen behöver vare ner 2-4 nivåer från roten sett om man skall ha tur att få fatt på denna...

Då det har hänt mig två gånger pga. en USB-kontroller i en extern disk skrev dessa två sektor (och bara dessa) vid unmount och rycka ur sladden så litar jag inte på NTFS någonsin mer - jag har aldrig förlorat filer i ext-filsystem och dess förelaga i Linux och jag har ändå pillat med linux sedan typ 1992 eller så med klart beta-nivåer på filsystem.

Jag har aldrig sett en single point to failure (förvisso två sektorer - men de skrevs samtidigt då dessa sektorer skrivs alltid vid mount/unmount) i ett filsystem som kan ge sådana konsekvenser i filstrukturer som i NTFS.

Med det här innebär inte att ext-filsystem eller andra filsystemsalternativ är kontrollerad säkra, utan bara konstaterat att NTFS inte är det och man skall inte lägga sina viktiga data på en extern USB-HD med NTFS på arkiv utan dubblett/backup på annan media då det som sagt räcker med 2 sektorer felskrivning, de två som alltid skrivs vid mount och unmount av volymen för att en 1-4 TB data skall bli till en sanslöst röra att reda ut...

Metadata och filnamn/filstruktur är oehört underskattat tills man en dag förlorar dem...

FAT i olika smaker kunde krascha ganska ordentligt, men det fanns alltid olika verktyg och med interaktion från användaren så kunde man rädda det mesta ändå och med sina filnamn och filhieraki kvar...

[BJ]

Då kan man alltså inte kontrollera om filsystemet på en
usb-hårddisk är som det ska, om det skrivs till dom
sektorerna efteråt med, när man avmonterar den?

Gäller det interna hårddiskar med?
Gör Linux likadant med ntfs?

[xxargs]

Eftersom jag och säkert fler har ärr i sinnet när det gäller krachade filsystem så fastnade jag på en rapport där man injicerar fel i filsystemens filpekare av olika slag på mer strukturerat sätt och sedan se vad som händer med filsystemen efteråt med olika simuleringar med virtuella maskiner. Rapporten har egentligen fokus på frågeställningen vad som händer med filsystemen när mediat börja få bitröta på filsystemskritiska sektorer och bör intressera alla som arkiverar på HD och kanske i bankfack.

Den ser ganska seriös ut, med i typisk LaTex-rapport format från universitet (där Google också nämns) etc. se http://pages.cs.wisc.edu/~swift/papers/ ... -dsn08.pdf där testet har gjorts på NTFS och ext3

Man kan säga att ingen av dessa filsystem har gjort bra ifrån sig, det finns mycket att förbättra - framförallt på filsystemcheck-sidan där relativt små insatser kan ge väldigt stora förbättringar då som det ser ut idag så används väldigt lite av filsystemens potentiella redundans när man skall städa upp en lortig filsystem, och i NTFS i vissa situationer förvärrar det hela till heltrasigt filsystem då den skriver över redundant data utan att ha lästs och som förloras för alltid och det blir följdfel som eskalerar - och det kan ske redan vid första ombootningen efter en datorhäng tex...

Till detta har man 'attitydproblem' på vad som är viktig data och båda systemen lita mera på sina (felaktiga) pekare än datat som ligger på plats och verifieras på annat sätt i tidigare steg. linux tog 'stryk' i testen i och med att volymen om-monteras till read only så fort minsta fel indikerats vilket förvisso skyddar innehållet bättre för vidare skador men blir en showstopper, medans NT gör olika saker vid start och drift i bakgrunden som inte syns eller medelas med olika recover-försök och ibland kan bli väldigt fel med förstörd data som följd - vilket som är värst kan man diskutera...

När man läst detta så inser man att programmerarna för filsystem för båda OS har sett filsystemkontrollen som ett nödvändigt ont och gjorts minsta möjligt på denna vid sidan av filsystemknackandet och man har inte funderat seriöst på filsystemcheckens förmåga att rädda upp ett trasigt system alls på den nivå som det finns potential för.

Att välja filsystem för långtidslagring ingen trivial historia då den helst skall klara bortfall av viktiga data i filsystemsviktiga delar utan att innehållet skadas eller görs oåtkommlig - systemet som tänkt längst i den vägen är förmodligen ZFS - ja om man inte lägger en okomprimerad tar-arkiv direkt på /dev/sdb... typ.

[MiaM]

På SCSI-disk tiden så kunde man teoretiskt ha flera datorer på samma SCSI-bus och därmed åtkomst av samma diskar från flera datorer samtidigt, men jag har aldrig sett det realiseras i verkligheten och det beror nog mycket på svårigheten på att administrera samma disk/filsystem med flera oberoende aktörer samtidigt för risken att filsystemet blir inkonsistent.

OpenVMS stöder givetvis detta

På VAX kan man nog inte använda detta på just SCSI men väl på CI (Cluster Interconnect, Digitals 80-tals-föregångare till SAN, tror det var 70mbps över koaxkablar). På Alpha kan man göra detta även över SCSI.

Detta kan dessutom ingå i röstningen om hur kluster ska formas och huruvida det finns tillräckligt maskiner för att forma ett fungerande kluster. För att ett fåtal "huvudmaskiner" i ett skitstort kluster ska kunna forma kluster och "vinna" omröstning så utser man en quorumdisk och den maskin som anses ha tagit kontroll över den disken får ett konfigurerbart antal bonusröster i omröstningen om vem som ska hålla koll på klustret. För att denna funktion ska kunna hållas av flera burkar så ansluts den disken via något interface som tillåter flera anslutna datorer samtidigt.

Förutom quorumfunktionen så kan man montera diskar med vanligt filsystem och klustermjukvaran ordnar så att det fungerar att läsa/skriva samma filsystem från flera burkar samtidigt. Allt detta fanns alltså klart och levererades redan på 80-talet.


P.S. vad gäller att återfå filer från NTFS-diskar med korrupt MFT så kan man i vissa fall använda filernas faktiska innehåll för att återskapa metadata. Det finns t.ex. program som letar reda på olika bildformat på korrupta diskar. Med Exif eller motsvarande fiskas tidsstämpel upp och sätts på filen. På så vis kan man sortera de återskapade filerna på fotograferingstidpunkt och därmed halvenkelt hålla ordning på vad som är vad trots att man tappat namnen. (I just den tillämpningen så heter ju filerna oftast ändå bara BILD1234.JPG från kameran).

Jag har btw inget minne av att på många år ha drabbats av korrupt filsystem som inte berott på korrupt hårdvara.

[xxargs]

Där kan jag nog hålla med - när det strular så är det oftast någon HW som strular - allt ifrån diskar som säger upp sig med bitröta och sökproblem, glapp i kabel och dum beteende på konverteringskort som mellan USB2/3 och disken i tex. externa diskar, tex vid glapp i kabeln eller under matningen i och ur av kontakten etc.

När man börja jaga på olika headers, 'magic numbers' etc. så är man inne på det som verkar kallas 'data carving' inom forensic-kretsar och då handlar det inte längre om att försöka få ut filerna med hjälp av filsystemets information och turfaktorn börja bli dominerande att tex. filerna ligger i följd och inte defragmenterat. det är detta som R-studio mfl. program gör när man inte får ordning på filstrukturen eller delar av denna. problemet är man ofta förlorar filnamnet om denna inte är gömd i filen på något sätt.