XFS: Ett problem i prestanda tänkbart orsakat av XFS

Det här kan bero av annat än just filsystemet XFS (men bättre sammanfattning av vad XFS är i Wikipedia). Även möjligen orsakad relaterat Linux stacken har utrymme för optimering av access till minne resp. kopiering av filer disk och mellan fysiskt olika diskar tvivlar jag på det.

• Disken har en mängd filer lagrade alla av samma syfte men varierande stora.
• De är ofta lagrade så att om vi sorterar dem efter filnamn (givet någon storlek eller blandat i storlek) kommer vi ha nästa fil i listan närmare föregående fil än typiskt någon av de senare filerna.

Lägger jag nu trådar som läser filer som filtrerar efter storlek på filerna i en mängd filnamn (första bokstaven alltid här) och har en mycket stor i antal filer och mycket låg i storlek (ex. 8 - 32 byte) medan denna konkurrerar kortare lista av utvalda filer större så kan de senare hamna i mycket märkbar periodvis starvation utan någon access till disken. Också att vi skriver "väldigt hårt" mot disken utan särskilt mycket i logiken eller OS i övrigt som bromsar.

Av och till när arbete gjorts för att kraftigt uttrycka detta med långa perioder av starvation hamnar tråden eller de två trådar som kraftigt läst i antar jag påtvingad tystnad utan att göra något alls för att antar jag ge annat möjlighet att komma åt disken. Men inte oftare än att beteendet kraftigt kan störa normal upplevelse av disken.

Jag tror att orsaken är att stödet till XFS tittar var det i disken som läser och skriver befinner sig och när den kan välja tenderar till att belö vad som kan befinna sig närmare det.

Det var (och är kanske fortfarande att visa sig igen) väldigt irriterande eftersom jag med ett ganska litet antal trådar behöver vänta på disken för att göra icke-relaterat arbete. Jag har inte alls van vid det här problemet med så få trådar som ett par tre stycken (jag kom fram till att för fil-listor att gå igenom enligt tidigare med åtminstone någon över några hundra tusen åtminstone är två trådar åtminstone inte sämre än fler trådar och troligen bättre medan frågan om det är bättre eller sämre än en lista mer bestäms av att personligt periodvist engagemang med två trådar blir väsentligt mer sällsynt och inkluderar tid där det naturligt faller ner till en tråd).

Men som sagt andra orsaker till det här kan finnas. Erfarenhet av själva hårdvarulösningen ger att den ibland när man gjort om filsystemet arbetar på sämre prestanda rörande en del en period (men jag minns inte om jag tidigare sett något liknande som detta: snarare tror jag konkret sämre mängd data per sekund vid tydligast kopiering av filer).

Jag kan tänka mig att det här är någon algoritm i XFS. Dels därför att jag kan se hur det vid annat arbete (och kanske detta tror jag också) kan förbättra prestanda. Samtidigt att antalet fall "arbets-profil" man tagit hänsyn är ganska begränsat vilket är vad jag sett för en del andra filsystem på Linux (inte minst NTFS varför jag ganska nyligen bestämt att inte ha några diskar alls med NTFS). D.v.s. bredare fall att hantera lämnande från Linux-samhällets-framtid och i det följande en mer långsam tid än områden kanske roligare och/eller mindre kompetenskrävande och/eller fodrande mindre insats i att lära sig tämligen komplex kod befintlig.

Men jag har väldigt vaga begrepp om hur man optimerar diskar nära hårdvaran. Jag tyckte dock att det här kanske kunde vara en förklaring av det som jag kunde föreställa mig är vad man laborerar med. Det är ju utan just någon kunskap alls om hårddiskar fungerar fysiskt ungefär vad jag kan föreställa mig att man kan optimera: Ett tänkt don (vem vet kanske finns det många sådana: Ingen aning) som rör sig över det som kallas disk och läser eller skriver med en kostnad beroende av hur långt den måste flytta sig mellan skrivningar.

Praktiskt har jag fått en naturlig lösning av det hela med var arbetet ligger från att resp. lista filer som arbetas sorteras är mycket mer varierat i storlek. D.v.s. viss motsvarande fragmentering ges samtidigt som att inte samma enorma antal filer öppnas och stängs per byte. Att det senare kan tänkas spela in ger antar jag en indikation om vad resp. prediktion påverkas av: Position från föregående fil vi befinner oss på snarare än någon statistisk centralitet från en grupp (eller åtminstone en ganska liten grupp: Lätt att ta fel när man läser sorterat för filer som ligger "bra lagrade" på disken).

Hade jag större hårdvarulösningar lagring kanske jag hade övervägt att försöka hitta eller göra en lösning där man enkelt kan koda eller konfigurera hur optimering sker (om vi antar optimering som tänkt här faktiskt är hur det sker med mätbart resultat) utifrån typen av filer som lagrade och hur arbetet ska ske. Det är ju trots allt när mycket data som här ganska tidsödande totalt så en del annars kanske ganska små skillnader lär väl kunna summera en he del tänker jag: Kanske rent av många dagar totalt. Men nu arbetar jag inte riktigt med hårdvaruplattformar för lagring där jag tror det har förutsättningar att vara värt besväret i att lära sig mjukvarustöd eller värre problemområdet för egen kod. Här kan jag se att andra typer av prediktioner kanske fungerar bättre i såväl prestanda som risk för att irritera mig när jag gör klart konfigurationen inför nästa tråd som ska startas.

PS

Förövrigt rörande:

"Linux kernel's support for XFS was originally available through patches from SGI. It was merged into the Linux kernel mainline for the 2.6 series, and separately merged in February 2004 into the 2.4 series in version 2.4.25,[4] making XFS almost universally available on Linux systems.[5] Gentoo Linux was the first Linux distribution to introduce an option for XFS to be used as the default filesystem in mid-2002.[6] Installation programs for the Arch, Debian, Fedora, openSUSE, Kate OS, Mandriva, Slackware, Ubuntu, VectorLinux and Zenwalk Linux distributions all offer XFS as a choice of filesystem, but few of these let the user create XFS for the /boot filesystems due to deficiencies and unpredictable behavior in GRUB, generally the default bootloader.[7]"

Från: XFS | Wikipedia

Bootar jag tre Linux-distributioner från USB-disk formaterad XFS med GRUB. Arch även om jag har den installerad som köpt på en nätdisk från Sygate har jag dock inte bootat från XFS (om det nu inte är vad den kör som köpt).

NTFS och Linux: Korrigera "Input/Output error" utan Windows och chkdsk

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:

• apps.ubuntu.com/cat/applications/ntfsprogs

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.

Linux: Ett enkelt abstrakt filsystem

Jag har full förståelse av att precis vad jag tänker mig att någon eller några borde komplettera Linux med som default långt ner finns för åtminstone bakåt i tiden mer påkostade lösningar (men idag säkert allt oftare i hemmen också). Men situationen är ju ändå att man har ett antal partitioner, diskar adderade m.m. introducerande kostnad i tid och slitage för att passa samman det hela när utrymme tenderar att gå scarce där den primära lösningen inte känns som ett helt nytt lagringssystem åtminstone mer omedelbart.

Samtidigt så länge man nöjer sig med att varje fil i sin helhet ligger på en partition eller rent av fysisk disk förstår jag inte varför ett enkelt abstrakt filsystem ovanpå allt i övrigt utan särskild inläsning, kunskap, annan kostnad associerad mig o.s.v. kunde införas (i mening utan att jag behöver göra det själv).

Och gärna störande om hela konceptet boot sektorer med något mer legacy mellan befintligt och OS då jag är upparbetat ganska skeptisk till en ev. mängd problem lite varstans i världen som funktion av hur väl de tas upp av normalt befintliga säkerhetslösningar eller förväntade problem. D.v.s. på flyttbara diskar förväntar sig folk vanligen inga problem så länge de ex. har lite bilder m.fl. filer man inte kör medan diskarna är allt oftare mer eller mindre små enkla datorer med saker som auto-startas vid mount eller för den delen mer uppenbart när hela datorn bootas upp.

Nu är jag inte 100% säker på hur allt kring open source projekt fungerar men antar att vem som helst kan ta en beställar-roll för att åtminstone som här mindre uttrycka just en färdig kravspecifikation och istället mer vad jag behöver för att förenkla min verksamhet nära hårddiskarna. Så kan sedan andra självorganisera tankarna vidare vad dom kan bättre än jag kan mina behov relaterat filsystem. Något av skönheten med hela konceptet. Vi skapar något tillsammans där man efter gjort sin del kan betrakta skapelsen av något större när andra gör sitt.

Känner jag kompetensen kring sådant här finns nog en fin och stabil lösning klar att ta ner om ett par månader lagom till det kanske inte otroligt blir dags till mer nöd-tvingad om-organisation av filer. Annars skulle det inte vara mycket alls med kunnandet om något relaterat detta. Mitt förtroende för självorganisationen av värde för mig och övriga världen är gott.