Vårt primära krav här är att inte behöva sitta och kompilera om diverse program relaterade NTFS på Linux eller ännu värre komplettera dem. Problematiken här på en ny My Book rörde fyra kataloger varav två eller tre var de kataloger som fanns på disken som köpt.
Efter att ha tömt den på cirka 1 - 1.5 T ej defekta kataloger eller filer löste jag problemet med ganska ofullständigt stöd för defekt NTFS på Linux (det mesta rekommenderande just chkdsk under Windows) genom att:
- Monterande disken (vilket troligen varken behövs eller egentligen är rekommenderat).
- Användande ntfsundelete för att ta ut ej raderade filer genom att använda -i gående över alla inodes.
- -O för att den återställer filer använda d.v.s. ej raderade.
- Återställande till annan disk än aktuell disk här. Det viktiga att vi återställer till annan plats.
- --force ej uteslutande därför att vi har disken redan monterad utan även därför att filsystemet är markerat smutsigt.
För raderade filer fick jag generellt inget försök att namnge dem innebärande att ntfsundelete skriver över samma fil i nya katalogen och endast de existerande filer skapas (med ett undantag). Men man kan ju låta ntfsundelete göra scan först (identifiera raderade filer som information om finns för) och sedan återställa alla inodes ej på den listan men som går att adressera.
Nackdelen som jag gjorde det är att de hierarkiska katalogstrukturerna förloras.
I allmänhet tror jag att det är väldigt klokt att aldrig använda NTFS om ej absolut nödvändigt och särskilt inte under Linux.
Jag har en del intressanta skärmdumpar på en del av dom mer fascinerande sidorna av defekterna denna disk råkade ut för som jag troligen återanvänder till. I allmänhet för My Book är min erfarenhet att de alltid numera för sista versionerna får dom har typen av fil varefter man löser dem och kompilerar dem ej NTFS (där de dessutom tror jag tappar en del särskilda funktioner som i princip bara är risk och förlorad prestanda mot disken): Sedan ännu för mig i alla fall går de felfria.
Så vitt jag vet är det här ända sättet att lösa input/output error på NTFS i Linux för att få ut filer på underliggande katalogsystem (d.v.s. faktiska felet blir ju ej löst här vilet tänkbart chkdsk hade klarat bara genom att ge katalogen nytt namn - ex samma -, skapat ev. meta-information rörande rättigheter m.m. saknat o.s.v. rent trivialt). ntfsfix från samma "paket" med NTFS program har aldrig för mig genom kanske 10 ytligt likartade problem gjort annat än markerat diskarna som smutsiga innebärande att de är markerade för Windows som problematiska fordrande chkdsk samt under Linux innebärande att diverse ntfs-program måste köras med --force. Någon gång ska jag pröva att göra det på frisk NTFS och se om programmet i så fall beter sig annorlunda. Aktuellt paket:
Att göra denna lilla operation lärde mig förövrigt allt möjligt om hur WN arbetar med diskarna innan de går ut. Ganska speciellt faktiskt och om jag ids faktiskt återställa diverse filer från 1971 (om jag kommer ihåg rätt) - 2006 jag ej haft på dem kanske jag återvänder till det. Från och med nu anar jag att när behov nytt utrymme ej är kritiskt att jag faktiskt kommer börja med att göra undelete på nya diskar.
Tänkbart beroende på rättigheterna kring ntfsprogs kanske det någon gång också blir av att utgå från lämpligt där till ett trevligt verktyg som parsar ut mer relevant information när disken är defunct. Samt gärna omvänt lägger till manuellt data för vad som nu är ofullständigt eller saknat för känt existerande filer.
Det skulle inte förvåna mig att nästan allt av de vanliga uppgifterna om komplexiteten i NTFS är falsk och istället beror av att man har svårt att separera under reverse engineering NTFS från operativsystemet under Windows.
Ext2, Ext3 eller Xfs?
Frågan är sedan vilket filsystem jag ska formatera till den här gången. ext2 har fungerat felfritt på My Book. Jag tror också jag har en eller två med ext3. Dock har jag en partition på intern hårddisk som sedan några veckor kör xfs med kod erfarenhet för åtminstone vissa typer filer rörande prestanda. Arbetande mot att lägga in data i nya filer sorterade på en WN Passport fick jag bäst prestanda inkl. all tid nödvändig på att flytta filer till denna partition och sedan processa därifrån med jämförbart sämre prestanda från en ext2 med väsentligt mer ledigt utrymme (xfs i kontrast totalt kanske 500 GB endast och med vid denna tidpunkt inte mer än 100 GB fritt d.v.s. normalt i min erfarenhet man börjar märka prestanda försämring från gissar jag fragmentering oavsett vad nu diverse verktyg rapporterar men gav ej sådana problem förrän närmare 50 GB fritt).
Dock har jag förutom små San-disk USB-sticks på 16 GB prövat XFS i övrigt. Och aldrig på en USB-disk. Efter formatering kommer jag dock ha den en period för data som skapas upp rörande statistiska relationer (förhoppningsvis räcker dess 3 T med viss komprimering i delar så att jag även denna gång kommer undan att behöva införa Squashfs - länkad kod kompilerar utan problem på Ubuntu men tycks vara beroende av kernel-version avseende komprimerings-algoritmer som stöds emellertid har jag själv standardiserat på "gzip" vilket stöds i alla alternativ - i Tiger Ant OS som jag annars anar är ett bra alternativ för riktigt stora filsystem där man sällan adressera rsp. del). Puppy Linux och diverse andra Linux man kör direkt från CD och USB använder förövrigt Squashfs eller nära besläktade lösningar.
Om XFS:
XFS is a high-performance 64-bit journaling file system created by Silicon Graphics, Inc (SGI) in 1993.[1] It was the default file system in the SGI's IRIX operating system starting with its version 5.3; the file system was ported to the Linux kernel in 2001. As of June 2014, XFS is supported by most Linux distributions, some of which use it as the default file system.
XFS excels in the execution of parallel input/output (I/O) operations due to its design, which is based on allocation groups (a type of subdivision of the physical volumes in which XFS is used- also shortened to AGs). Because of this, XFS enables extreme scalability of I/O threads, file system bandwidth, and size of files and of the file system itself when spanning multiple physical storage devices.
XFS ensures the consistency of data by employing metadata journaling and supporting write barriers. Space allocation is performed via extents with data structures stored in B+ trees, improving the overall performance of the file system, especially when handling large files. Delayed allocation assists in the prevention of file system fragmentation; online defragmentation is also supported. A feature unique to XFS is the pre-allocation of I/O bandwidth at a pre-determined rate, which is suitable for many real-time applications; however, this feature was supported only on IRIX, and only with specialized hardware.
A notable XFS user, NASA Advanced Supercomputing Division, takes advantage of these capabilities deploying two 300+ terabyte XFS filesystems on two SGI Altix archival storage servers, each of which is directly attached to multiple Fibre Channel disk arrays.[2]
Från: XFS | Wikipedia
En tänkbar fördel med ext3 för viss sladd-problematisk användning
En egenskap hos ext3 och menar att Wikipedia i delar drar fel slutsats rörande är dock:
Writeback (highest risk)
Only metadata is journaled; file contents are not. The contents might be written before or after the journal is updated. As a result, files modified right before a crash can become corrupted. For example, a file being appended to may be marked in the journal as being larger than it actually is, causing garbage at the end. Older versions of files could also appear unexpectedly after a journal recovery. The lack of synchronization between data and journal is faster in many cases. JFS uses this level of journaling, but ensures that any "garbage" due to unwritten data is zeroed out on reboot.
Från: ext3 | Wikipedia
Vågar man sig ej på att "trycka till" "USB-kontakterna" hos sina nyköpta WN-diskar man flyttar runt (WN har problem i konstruktionen på dessa i mening av att sladden för lätt lossnar: Ända märket USB-diskar jag någonsin haft sådana problem med) är tänkbart ext3 ett bra alternativ. Ty jag tror - men är ej säker - att Wikipedia har fel rörande korruption här och det snarare är att man vid problem av typen sladden lossnar förlorar data underskrivande (typ filen) men ej lika troligt får korrupta filer svåra att bli av med.
Diskussion XFS vs ext4 ("XFS --if it's more robust, why are we using ext4 instead?" - för diskar av typer aktuella här handlar allt rörande "robusthet" aktuell med ext2 och framåt såväl som XFS i min erfarenhet om ingen praktisk skillnad trolig överhuvudtaget - NTFS genom tänkbart bl.a. sämre kod för att hantera filsystemet på Linux - är en annan fråga utan skillnad i värde kommer helt ner till prestanda (även om jag gärna prövar försiktigt nya kombinationer om än ännu utan att det visat problem). För mer komplexa disksystem - d.v.s. ej vanliga interna hårddiskar i datorn eller USB-diskar - jag saknar erfarenhet av kan det vara annorlunda.
Rörande små-filer snarare än de stora diskuterade på länkad sida har jag omfattande erfarenhet av därför att jag regelmässigt förfaller till att utnyttja skapande av små-filer som del av sortering när tidsstress är obefintlig och alternativ är komplext gäller i min erfarenhet att prestandan är mycket sämre för såväl extNN och XFS men i särklass sämst för NTFS. Nyligen (igår) jämförde jag filkopiering ut från den i hårdvara senare och snabbare My Book disken jag höll på att tömma med prestandan från en av de interna diskarna, resp. en äldre extern (de båda senare i skapelse år många år äldre). Den sista var cirka 10 ggr snabbare i kopering från ext2 jämfört med NTFS. Den interna disken fick jag ej värden att se av någon anledning. Samma skillnad i prestanda såg jag nyligen för NTFS på WN Passport (som jag aldrig haft de för My Book typiska defunct en gång nära in på kö för: Men jag såg nyligen på nätet att det verkar vara ganska vanligt med My Book problem: Lite spekulativt klarar WN bra av att bygga hårddiskar medan de suger fett på allt runt programmering där de börjat stoppa in "smarta funktioner" i de lite dyrare diskarna som bara gör dem slöa och föga tillförlitliga - Sygate i kontrast har jag inte en ända gång trors många år äldre diskar som varit under mycket värre mobila äventyr än någon WN haft problem med. Emellertid vissa "pris-tekniska aspekter" på Sygate resp. WN gör att jag har cirka åtta gånger fler WN diskar med huvuddelen för My Book köpta efter att deras naturliga problem var välkända för mig).
D.v.s. med små-filer är man redan förlorad från allt vad god prestanda heter oavsett filsystem och grad av fragmentering. Åtminstone min Linux har helt enkelt för stort over-head öppnande och stängande en fil oberoende av storlek. Vidare är min erfarenhet praktiskt att man alltid är djävligt dum som förfaller till skapa upp små-filer som data-representation. En viss andel oavsett planerat eller inte tenderar att kvarstå i backup eller tvingande behov och kan alltid år efter år upplevas som för dyr i tid direkt att representera om och ligger istället att kostar kontinuerlig prestanda i direkt användning och/eller genom att öka sannolikheten för fragmentering av disken.
Jag tror jag prövar XFS på disken. Själva användningen är sådan att stora delar av access till datat kan ske lokalt på disken utan kopiering över USB-gränssnittet vilket jag tror gör att man vinner mer på ett snabbare filsystem. Dessutom gillar jag att XFS är ett gammalt filsystem som funnits länge och ej ganska ny programmerat.
