Mycket snabb skrivning till NTFS med kommande Linux 5.15

Permalänk
Medlem

Mycket snabb skrivning till NTFS med kommande Linux 5.15

Jag har redan testat detta, genom att bygga 5.15-rc6
Det finns inget passande "mount"-kommando än. Men kringgås genom att ange filtyp ntfs3 i /etc/fstab

Resultat med "gamla" Linux:

echo 3 >/proc/sys/vm/drop_caches; time ( dd if=/dev/zero of=/tmp2/tempfile bs=1M count=2048; sync )
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 16.3061 s, 132 MB/s

real 0m17.862s
user 0m0.001s
sys 0m2.596s

Och med "nya":

echo 3 >/proc/sys/vm/drop_caches; time ( dd if=/dev/zero of=/tmp2/tempfile bs=1M count=2048; sync )
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 0.856449 s, 2.5 GB/s

real 0m5.000s
user 0m0.008s
sys 0m0.853s

Kändes blixtsnabbt! Nästan fyra gånger snabbare.

Permalänk
Medlem

Varför skulle man bry sig om NTFS som Linuxanvändare? Personligen har jag aldrig sett behovet av annat än fat32, ext{3,4} och btrfs.

Permalänk
Rekordmedlem

Vem vågar använda NTFS på ett ställe där det inte är ett tvång ?
tvärt om vore mer användbart, nix filsystem i win.

Det finns väl kanske ett berättigande, för att lättare kunna göra recoverys på win diskar som flippat ur pga dåliga filsystem.

Permalänk
Medlem
Skrivet av mrqaffe:

Vem vågar använda NTFS på ett ställe där det inte är ett tvång ?
tvärt om vore mer användbart, nix filsystem i win.

Det finns väl kanske ett berättigande, för att lättare kunna göra recoverys på win diskar som flippat ur pga dåliga filsystem.

NTFS är ett tekniskt mer avancerat filsystem än ext2/3/4, men om du vill köra dem på Windows så går det bra att göra det med programvara från samma bolag som donerat den här koden (Paragon). Kan också läsa (men inte skriva) XFS och BtrFS. Det finns massor med gratisprogram som gör samma sak, fast kanske inte i samma hastighet.

På det hela taget finns det bara ett filsystem som vanligt används på Linux som är väsentligt bättre än NTFS, och det är ZFS. Där saknas det ett riktigt bra stöd idag - Microsofts svar är ReFS, som är stabilt med långsamt. BtrFS är intressant (och snabbt), men varje gång jag tittar mer på det så hittar jag något svart hål som gör mig mörkrädd. Läste lite om hur det fungerar med en pool med flera diskar när en försvinner och sen kommer tillbaka, och det är ju så att man blir mörkrädd.

Permalänk
Medlem
Skrivet av orp:

Varför skulle man bry sig om NTFS som Linuxanvändare? Personligen har jag aldrig sett behovet av annat än fat32, ext{3,4} och btrfs.

Skrivet av mrqaffe:

Vem vågar använda NTFS på ett ställe där det inte är ett tvång ?
tvärt om vore mer användbart, nix filsystem i win.

Det finns väl kanske ett berättigande, för att lättare kunna göra recoverys på win diskar som flippat ur pga dåliga filsystem.

Googla "extern hårddisk". SJälv flytter jag filer mellan datorer ibland.

(förlåt för att jag var dryg)

Permalänk
Medlem

Testerna med bara 2GB filstorlek säger inte så mycket om hur fort lagringen tar emot data då det mesta är kvar inom datorns RAM-cache - däremot kanske det belyser lite på den inre mekaniken för drivrutinen.

NTFS är långsam - speciellt när det gäller att öppna och stänga småfiler då det är mycket overhead och att man står och skriver i $MFT och $Log upp till 10 kByte i sektor efter sektor-skrivning efter varandra på ungefär samma ställe i en serie för varje fil som skapas, öppnas och stängs (i windows alltså, linux buffrar i alla fall skrivningarna i RAM innan det flushas ut i lämplig intervall)

Men det drar fortfarande en väldig massa CPU och enkeltrådat och är det som sätter gränsen i hur många transaktioner det kan hinna med, och det är rätt lika i windows som Linux. - vi pratar om faktor 5-10 ggr långsammare än ext3/4 och BTRFS. - skall man hantera mycket småfiler och thumbnails så är NTFS inte valet, och på SMR-diskar är för närvarande NTFS den sämsta filsystemet av alla och det beroende på det som skrevs i andra styckets med rent tortyrliknande skrivningar på nästan samma ställen hela tiden mot disken när det körs under windows.

Skillnaden blir mindre ju större filkropp som skall skrivas då det begränsas allt mer av transporthastigheten mot lagringen.

När man gör sådana tester med skrivning av större mängd data bör man också ta i med filstorlek - typ 10 ggr RAM-minnet i storlek på datorn så att det verkligen tvingas ut att skriva på disken och inte får sina tider efter hur bra cache-minnet fungerar.

---

Det som också är intressant är att göra 10 miljoner filer-testet med 32 byte hashvärde var fil i en mapp och se hur det tar i tid - när jag provade med ruby-skript hittad på Internet så tog det 3951 sekunder under windows (och efter att defender-scanningen plockats bort för disken/mappen - annars dubblas tiden), 3471 sekunder under Linux, Ext4 389 sekunder och BTRFS 377 sekunder.

I fallet NTFS så var systemet mättad både i windows och Linux (läs NTFS-drivrutinen arbetade max och bara enkeltrådat) och lasteb på ruby som körde skriptet runt 15%, i fallet ext4 och BTRFS så var ruby mättat 100% och system-resursförbrukningen runt 15-25% - svårt att veta då skrivningen mot disk är multitrådat. - då tiderna mellan ext4 och BTRFS är nära lika och båda lastar 100% på Ruby så är det ruby som flaskar och man behöver skriva ett C-program som verkligen producerar skrivningar och kanske flertrådat för att fylla upp ext4 och BTRFS kapacitet när det gäller att skapa småfiler...

skriptet som gjorde jobbet var

require 'digest' require 'benchmark' hash = {} 10_000_000.times do key = Digest::MD5.hexdigest(rand.to_s) value = Digest::MD5.hexdigest(rand.to_s) hash[key] = value end FileUtils.mkdir_p "dir_flat" FileUtils.mkdir_p "dir_deep" puts Benchmark.measure { hash.each do |key,value| File.write "./dir_flat/#{key}", value end } puts Benchmark.measure { hash.each do |key,value| File.read "./dir_flat/#{key}" end } puts Benchmark.measure { hash.keys.each do |key| dir_path = "./dir_deep/#{key[0..1]}/#{key[2..3]}/" FileUtils.mkdir_p dir_path end } puts Benchmark.measure { hash.each do |key,value| dir_path = "./dir_deep/#{key[0..1]}/#{key[2..3]}/" File.write dir_path + key, value end } puts Benchmark.measure { hash.each do |key,value| dir_path = "./dir_deep/#{key[0..1]}/#{key[2..3]}/" File.read dir_path + key end }

detta går säkert att fila till mycket bättre

och jag hämtade närmaste ruby-miljö hos https://rubyinstaller.org/ att installera i windows och i linux samma sak om det inte redan finns installerad.

med 'irb' kan man köra raderna interaktivt om man vill

Permalänk
Medlem
Skrivet av mpat:

NTFS är ett tekniskt mer avancerat filsystem än ext2/3/4, men om du vill köra dem på Windows så går det bra att göra det med programvara från samma bolag som donerat den här koden (Paragon). Kan också läsa (men inte skriva) XFS och BtrFS. Det finns massor med gratisprogram som gör samma sak, fast kanske inte i samma hastighet.

På det hela taget finns det bara ett filsystem som vanligt används på Linux som är väsentligt bättre än NTFS, och det är ZFS. Där saknas det ett riktigt bra stöd idag - Microsofts svar är ReFS, som är stabilt med långsamt. BtrFS är intressant (och snabbt), men varje gång jag tittar mer på det så hittar jag något svart hål som gör mig mörkrädd. Läste lite om hur det fungerar med en pool med flera diskar när en försvinner och sen kommer tillbaka, och det är ju så att man blir mörkrädd.

ZFS finns inte i Linux utan det måste installeras separat. Med stöd för ntfs i kärnan blir det enklare för många som kör både Linux och Windows. Nu får vi fullt stöd där man kan skriva komprimerade filer, vilket jag saknade tidigare.

Permalänk
Medlem
Skrivet av xxargs:

Testerna med bara 2GB filstorlek säger inte så mycket om hur fort lagringen tar emot data då det mesta är kvar inom datorns RAM-cache - däremot kanske det belyser lite på den inre mekaniken för drivrutinen.

NTFS är långsam - speciellt när det gäller att öppna och stänga småfiler då det är mycket overhead och att man står och skriver i $MFT och $Log upp till 10 kByte i sektor efter sektor-skrivning efter varandra på ungefär samma ställe i en serie för varje fil som skapas, öppnas och stängs (i windows alltså, linux buffrar i alla fall skrivningarna i RAM innan det flushas ut i lämplig intervall)

Men det drar fortfarande en väldig massa CPU och enkeltrådat och är det som sätter gränsen i hur många transaktioner det kan hinna med, och det är rätt lika i windows som Linux. - vi pratar om faktor 5-10 ggr långsammare än ext3/4 och BTRFS. - skall man hantera mycket småfiler och thumbnails så är NTFS inte valet, och på SMR-diskar är för närvarande NTFS den sämsta filsystemet av alla och det beroende på det som skrevs i andra styckets med rent tortyrliknande skrivningar på nästan samma ställen hela tiden mot disken när det körs under windows.

Skillnaden blir mindre ju större filkropp som skall skrivas då det begränsas allt mer av transporthastigheten mot lagringen.

När man gör sådana tester med skrivning av större mängd data bör man också ta i med filstorlek - typ 10 ggr RAM-minnet i storlek på datorn så att det verkligen tvingas ut att skriva på disken och inte får sina tider efter hur bra cache-minnet fungerar.

---

Det som också är intressant är att göra 10 miljoner filer-testet med 32 byte hashvärde var fil i en mapp och se hur det tar i tid - när jag provade med ruby-skript hittad på Internet så tog det 3951 sekunder under windows (och efter att defender-scanningen plockats bort för disken/mappen - annars dubblas tiden), 3471 sekunder under Linux, Ext4 389 sekunder och BTRFS 377 sekunder.

I fallet NTFS så var systemet mättad både i windows och Linux (läs NTFS-drivrutinen arbetade max och bara enkeltrådat) och lasteb på ruby som körde skriptet runt 15%, i fallet ext4 och BTRFS så var ruby mättat 100% och system-resursförbrukningen runt 15-25% - svårt att veta då skrivningen mot disk är multitrådat. - då tiderna mellan ext4 och BTRFS är nära lika och båda lastar 100% på Ruby så är det ruby som flaskar och man behöver skriva ett C-program som verkligen producerar skrivningar och kanske flertrådat för att fylla upp ext4 och BTRFS kapacitet när det gäller att skapa småfiler...

Nej filerna är skrivna! Ligger inte i någon buffert. Väsentligt snabbare än tidigare!

Permalänk
Medlem

ahh.. - du hade sync efter 'dd', missade det - ok, då ger jag mig

Permalänk
Medlem
Skrivet av fumped:

Googla "extern hårddisk". SJälv flytter jag filer mellan datorer ibland.

(förlåt för att jag var dryg)

Varför ska jag googla extern hårddisk? Alla mina maskiner kör Linux så ext4 fungerar iaf på min externa hårddisk.

Permalänk
Medlem
Skrivet av orp:

Varför ska jag googla extern hårddisk? Alla mina maskiner kör Linux så ext4 fungerar iaf på min externa hårddisk.

Min poäng var att man ibland behöver bry sig om NTFS som linuxanvändare när man behöver flytta filer till diskar som är formaterade med NTFS som bekanta drar med sig ibland

Permalänk
Medlem

NTFS används bara för dataöverföring mellan win-miljö och Linux-miljö - inget man lagrar viktig data på utan någon backup på något annat ställe samtidigt.

Jag har också bränt mig på NTFS och betrakta den som rysk roulette där man inte är säker på att filsystemet hittas nästa gång disken ansluts trots att man tycker sig gjort allt rätt vid avmontering... ... speciellt inte i användning på externa USB-diskar.

Finns ingen anledning att använda NTFS som någon system eller lagringsfilsystem när det finns bättre, snabbare och mer stryktåliga versioner.

Permalänk
Medlem
Skrivet av mpat:

NTFS är ett tekniskt mer avancerat filsystem än ext2/3/4, men om du vill köra dem på Windows så går det bra att göra det med programvara från samma bolag som donerat den här koden (Paragon). Kan också läsa (men inte skriva) XFS och BtrFS. Det finns massor med gratisprogram som gör samma sak, fast kanske inte i samma hastighet.

På det hela taget finns det bara ett filsystem som vanligt används på Linux som är väsentligt bättre än NTFS, och det är ZFS. Där saknas det ett riktigt bra stöd idag - Microsofts svar är ReFS, som är stabilt med långsamt. BtrFS är intressant (och snabbt), men varje gång jag tittar mer på det så hittar jag något svart hål som gör mig mörkrädd. Läste lite om hur det fungerar med en pool med flera diskar när en försvinner och sen kommer tillbaka, och det är ju så att man blir mörkrädd.

Bara för att ett filsystem är mer avancerat gör det inte bättre. Däremot kan det vara mer generellt så att det inte är riktigt dåligt på något, men inte heller extremt bra. Allt beror på den tillämpning som används.

Permalänk
Medlem
Skrivet av ehsnils:

Bara för att ett filsystem är mer avancerat gör det inte bättre. Däremot kan det vara mer generellt så att det inte är riktigt dåligt på något, men inte heller extremt bra. Allt beror på den tillämpning som används.

Nya NTFS-koden i Linux har välsignats av Microsoft. Stor skillnad mot när Ballmer härjade. Preliminär release är vid Halloween.
Själv kommer jag använda NTFS oftare nu när det är snabbt och komprimerbart.

Permalänk
Medlem

hehe äntligen kommer ihåg när skrivstöd kom till NTFS och blev så besviken på hastigheten det var kring 2009.
Har aldrig använt NTFS ses dess körde ett program för att kunna komma åt ext4-diskar från Windows istället.

Permalänk
Medlem
Skrivet av Meto:

hehe äntligen kommer ihåg när skrivstöd kom till NTFS och blev så besviken på hastigheten det var kring 2009.
Har aldrig använt NTFS ses dess körde ett program för att kunna komma åt ext4-diskar från Windows istället.

Nu blir det snabbt!
Jag har vissa backuper (musik och video) på extern USB-3, och då är det bra att det är NTFS! Alltså något man kan ta med utan att vara rädd om. All viktig data hemma har jag på en 10 TB stor disk-server med ext4.
Jag testade att köra backup till USB-3. Formaterade till NTFS och körde backup av ca 800 GB data från min server. Gick mycket snabbt och disken var helt ofragmenterad!

Permalänk
Medlem

Labbade med NTFS under Linux nån gång i mitten på 00-talet. Det var nån ensam kille som hade ett projekt för det. Det funkade att läsa och skriva i NTFS, men det var oanvändbart långsamt vad jag minns.

Kan ju vara användbart att det finns ordentligt stöd nu, exempelvis om man dualbootar och vill komma åt filer på Win-disken.

Permalänk
Medlem
Skrivet av Irre:

ZFS finns inte i Linux utan det måste installeras separat. Med stöd för ntfs i kärnan blir det enklare för många som kör både Linux och Windows. Nu får vi fullt stöd där man kan skriva komprimerade filer, vilket jag saknade tidigare.

ZFS finns med i Ubuntu-kärnan.

Permalänk
Medlem
Skrivet av lord_dubbdäck:

Labbade med NTFS under Linux nån gång i mitten på 00-talet. Det var nån ensam kille som hade ett projekt för det. Det funkade att läsa och skriva i NTFS, men det var oanvändbart långsamt vad jag minns.

Kan ju vara användbart att det finns ordentligt stöd nu, exempelvis om man dualbootar och vill komma åt filer på Win-disken.

Precis. Gamla ntfs-3g var slö och orsakade fragmentering. Komprimerade filer kunde inte skrivas alls. Release från kernel.org borde komma inom ett par veckor. Gentoo och Arch-linux är snabba medan de andra nog dröjer.

Permalänk
Medlem
Skrivet av Cloudstone:

ZFS finns med i Ubuntu-kärnan.

Oracle äger tyvärr ZFS och de vill säkert tjäna pengar på stora kunder. Tidigare kunde bara gamla versioner installeras utom på FreeBSD där ZFS där ingick i kärnan. Hur det är nu vet jag inte.

Edit: Linus Torvalds, creator of the Linux operating system, warned developers not to use an Oracle-owned file system because of the company's 'litigious nature
https://www.businessinsider.com/linux-linus-torvalds-oracle-f...

Permalänk
Medlem
Skrivet av Irre:

Oracle äger tyvärr ZFS och de vill säkert tjäna pengar på stora kunder. Tidigare kunde bara gamla versioner installeras utom på FreeBSD där ZFS där ingick i kärnan. Hur det är nu vet jag inte.

Beror på licensen. ZFS är licensierat under CDDL, vilket inte är kompatibelt med GPL2, men däremot med MIT/BSD-licensen som FreeBSD använder.

Citat:

Edit: Linus Torvalds, creator of the Linux operating system, warned developers not to use an Oracle-owned file system because of the company's 'litigious nature
https://www.businessinsider.com/linux-linus-torvalds-oracle-f...

Problemet med det är att BtrFS också är utvecklat av Oracle.

Permalänk
Hedersmedlem
Skrivet av xxargs:

NTFS används bara för dataöverföring mellan win-miljö och Linux-miljö - inget man lagrar viktig data på utan någon backup på något annat ställe samtidigt.

Det stämmer väl iofs in på typ alla filsystem? Spelar ingen roll hur bra filsystemet är, man lagrar aldrig någon viktig data någonstans utan backup. ZFS är ju skitbra t.ex. genom att det kan "heala" bitrot etc, men det hindrar dig inte från att skriva lite fel på ett rm-kommando någonstans...

Sedan finns det ju många miljoner Windows-servrar och datorer i hela världen som lagrar sin data på NTFS-volymer, det är inte något generellt dåligt filsystem som går sönder hela tiden.

Permalänk
Medlem

Man skall vara lite försiktig med ZFS-rekommendationer idag om det handlar om externa USB-lagringsenheter - dels för att lagring 6-8TB storlek och nedåt är SMR-diskar från samtliga tillverkare numera och det andra att en del USB-kabinett stänger av spindeln när det inte är någon dataöverföring på ett tag (läs WD... men även en del diskdockor) och därmed uppspinningstider innan disken svarar igen och det kan vara farligt nära 8 sekunder och krockar med att ZFS kickar diskar som inte svarar inom 8 sekunder! - så både uppspinningstid av disk och att disken inte svarar inom 8 sekunder när en SMR-disk håller på att nödstäda sin PMR-area för att kunna ta emot nya skrivkommandon är en källa till risk för strul och dataförlust om man använder ZFS på externa USB-enheter.

Man skall komma ihåg att externa USB-diskar är inte NAS/server-diskar som svarar garanterat inom 8 sekunder utan det är konsumentdiskar som kan hålla på att rota med omläsningar (vid läsroblem) över 30 sekunder till flera minuter innan disken svarar igen - samma sak vid nödstädande av PMR-area i SMR-disk...

För en enda USB-disk som lagring klarar det sig för det mesta bra med ZFS (ja förutom SMR-diskens risk att inte svara inom tid när den nödstädar sin PMR-area, som i sin tur är beroende på vad som skrivits innan, vilket kan vara svårt att testa fram med testskrivningar innan i utvärdering om man inte misstänker just här typen av problem) men bygger man pooler med flera externa USB-diskar och dessutom i kabinett som stänger av spindeln på disken så är man ute på hal is - Har en kamrat som har kämpat med detta för sin egen del då han som nyfrälst ZFS-fan för ett antal år sedan la all sin data på just ZFS på externa diskar (WD-book så klart...) och i olika pooler och fick trubbel långt senare av ovanstående skäl, och senare hjälpa andra i samma situation med ZFS-volym över flera externa USB-diskar när han lärt sig hur man löser detta och avråder nu å det bestämdaste för detta och nu använde BTRFS istället för all lagring på externa USB-diskar.

Hans förtroende för ZFS blev nog lite tilltufsad av detta då det gav mycket mer strul och rädsla av att förlora data permanent än förväntad nytta och skydd av data som utlovats och marknadsförts med ZFS - bara för 8 sekunders regeln sätter krokben, som dessutom är hårdkodad i ZFS...

Till detta är inte ZFS känd för att ha några bra reparationsverktyg eller extraktionsverktyg av filer ur en kraschad filsystem (vilket BTRFS har och har fungerat när jag provat, även om det för ZFS del förbättras sakta med openZFS och debuggandet där så det kanske finns något användbart numera) om man får filsystemknas och det är lite glaskanon över det hela - starkt medans det fungerar men splittras i småbitar när första sprickan väl kommer och man har helt enkelt sagt att man få förlita på sina backuperna när skiten träffat fläkten i ZFS-världen. - och vi vet alla hur det är med backuper den dagen det skiter sig...

Jag vet inte hur skrivordningen är med ZFS-filsystem på tex. en SMR disk och hur snabbt det fyller på diskens PMR-area när disken används hårt med läsning och skrivning med massor av små och stora filer kontinuerligt och hur fort det går in i väggen och blir trött (eller att disken kickas) - men jag vet att BTRFS är väldigt snäll mot SMR diskar och ytterst sällan slår i taket (dvs. blir långsam för att disken börja nödstäda sin PMR-area) och dessutom kickas inte diskar ut även om svarstiden är långt över 8 sekunder.

och hittills efter > 5 år har jag aldrig förlorat data på BTRFS som beror på filsystemet, samma kan jag inte säga om NTFS (som lärde mig det här med minst dubbla backupper den hårda vägen, svider fortfarande när jag tänker på det) och inte heller mdadm-RAID som korrumperar på ovanpåliggande filsystem - har nu hänt 2 gånger med ett par års mellanrum - svårjagade fel...

Permalänk
Hedersmedlem
Skrivet av xxargs:

Man skall vara lite försiktig med ZFS-rekommendationer idag om det handlar om externa USB-lagringsenheter - dels för att lagring 6-8TB storlek och nedåt är SMR-diskar från samtliga tillverkare numera och det andra att en del USB-kabinett stänger av spindeln när det inte är någon dataöverföring på ett tag (läs WD... men även en del diskdockor) och därmed uppspinningstider innan disken svarar igen och det kan vara farligt nära 8 sekunder och krockar med att ZFS kickar diskar som inte svarar inom 8 sekunder! - så både uppspinningstid av disk och att disken inte svarar inom 8 sekunder när en SMR-disk håller på att nödstäda sin PMR-area för att kunna ta emot nya skrivkommandon är en källa till risk för strul och dataförlust om man använder ZFS på externa USB-enheter.

Man skall komma ihåg att externa USB-diskar är inte NAS/server-diskar som svarar garanterat inom 8 sekunder utan det är konsumentdiskar som kan hålla på att rota med omläsningar (vid läsroblem) över 30 sekunder till flera minuter innan disken svarar igen - samma sak vid nödstädande av PMR-area i SMR-disk...

För en enda USB-disk som lagring klarar det sig för det mesta bra med ZFS (ja förutom SMR-diskens risk att inte svara inom tid när den nödstädar sin PMR-area, som i sin tur är beroende på vad som skrivits innan, vilket kan vara svårt att testa fram med testskrivningar innan i utvärdering om man inte misstänker just här typen av problem) men bygger man pooler med flera externa USB-diskar och dessutom i kabinett som stänger av spindeln på disken så är man ute på hal is - Har en kamrat som har kämpat med detta för sin egen del då han som nyfrälst ZFS-fan för ett antal år sedan la all sin data på just ZFS på externa diskar (WD-book så klart...) och i olika pooler och fick trubbel långt senare av ovanstående skäl, och senare hjälpa andra i samma situation med ZFS-volym över flera externa USB-diskar när han lärt sig hur man löser detta och avråder nu å det bestämdaste för detta och nu använde BTRFS istället för all lagring på externa USB-diskar.

Hans förtroende för ZFS blev nog lite tilltufsad av detta då det gav mycket mer strul och rädsla av att förlora data permanent än förväntad nytta och skydd av data som utlovats och marknadsförts med ZFS - bara för 8 sekunders regeln sätter krokben, som dessutom är hårdkodad i ZFS...

Till detta är inte ZFS känd för att ha några bra reparationsverktyg eller extraktionsverktyg av filer ur en kraschad filsystem (vilket BTRFS har och har fungerat när jag provat, även om det för ZFS del förbättras sakta med openZFS och debuggandet där så det kanske finns något användbart numera) om man får filsystemknas och det är lite glaskanon över det hela - starkt medans det fungerar men splittras i småbitar när första sprickan väl kommer och man har helt enkelt sagt att man få förlita på sina backuperna när skiten träffat fläkten i ZFS-världen. - och vi vet alla hur det är med backuper den dagen det skiter sig...

Jag vet inte hur skrivordningen är med ZFS-filsystem på tex. en SMR disk och hur snabbt det fyller på diskens PMR-area när disken används hårt med läsning och skrivning med massor av små och stora filer kontinuerligt och hur fort det går in i väggen och blir trött (eller att disken kickas) - men jag vet att BTRFS är väldigt snäll mot SMR diskar och ytterst sällan slår i taket (dvs. blir långsam för att disken börja nödstäda sin PMR-area) och dessutom kickas inte diskar ut även om svarstiden är långt över 8 sekunder.

och hittills efter > 5 år har jag aldrig förlorat data på BTRFS som beror på filsystemet, samma kan jag inte säga om NTFS (som lärde mig det här med minst dubbla backupper den hårda vägen, svider fortfarande när jag tänker på det) och inte heller mdadm-RAID som korrumperar på ovanpåliggande filsystem - har nu hänt 2 gånger med ett par års mellanrum - svårjagade fel...

Hade han någon backup på datat då?

Permalänk
Medlem

vet inte exakta detaljer

Det var backup men också arkiv - och att problemet var lika på flera setup med multipla drivers med samma typ av ZFS-pool med samma krångel att man inte fick upp alla diskar i poolen hur han än försökte med olika startordningar - nu var han förnuftig nog att inte göra något förhastat och rådfråga hos ZFS-gurus först om det är ZFS-haveri på gång och blivit lite guru själv på kuppen efter händelsen. Dock har han uppenbarligen tappat förtroende för ZFS på externa USB-diskar efter detta och nu kör BTRFS enkom på externa USB-diskar och plötsligt börja talar väl om BTRFS också till skillnad från flera år sedan då det var tummen ned och man skulle satsa på 'riktig' filsystem (ZFS) enligt kamraten - men det skall erkännas att BTRFS är i betydligt bättre skick i dag än för 4-5 år sedan när jag hoppade på det, men jag har alltid räknat med strul sker och inte blankt förlitat sig på en 'perfekt' filsystem - och jag provade mycket innan BTRFS fick förtroendet att lagra min data - och alltid i 2 upplagor på olika medier.

Så för ZFS - inga SMR-diskar, inga avstängningar av spindlar och sleep-läge när det inte är datartrafik, och att det är server/NAS-diskar med garanterat respons inom 8 sekunder och inte är generiska/konsumentdiskar (vilket i stort sett utesluter all användning av externa USB-diskar för ZFS om lagringen skall vara tillförlitlig).

Därav kan man inte säga att det är 'bara' att använda ZFS som filsystem på allt som lagrar data till vem som helst - för att den skall fungera bra så måste förutsättningarna också vara bra och det är inga fingrar mellan som tar smällen när det krånglar.

---

För BTRFS så hade jag en testsituation det bara inte gick att rädda ut några filer från BTRFS-filsystemet efteråt och det var i samband med bcache och backendsnurrdisk och skrivning i writeback-mode.

En del SSD firmware pallar inte för det i längden då dess trimtabell med reallokeringar snurrar ihop sig och kapsejsar med längre och längre responstid (troligen någon grad av exponentiell ökning då det går fort i slutet) på SSD men kan ta lång tid innan det inträffar med normal användning. - problemet är den totala katastrofen för filsystemet som blir följden när det väl händer...

Med användning av sidokanals-deduplicerare på 4k-sektornivå som 'bees' för BTRFS som kör deduplicering genom bcache så får man problemet inom ett dygn, oftast över natten om man startar det innan man lägger sig och då beroende på att responstiden till slut är så lång för SSD att Linux-OS kickar ut SSD:n ur systemet - vilket inträffar först när disken inte svarar inom flera minuter - lite varning ser man i dmesg innan med att det antal gånger ändrar tidkonstanten för diskens kommunikation och sedan klaga mer och börja med bus-reset allt mer ofta och sedan kickas SSD-disken

Då gick det inte att rädda någon data med BTRFS egna extrakt-verktyg och efter lite analys insåg jag att det i stor sett inte fanns någon metadata alls skriven på disken utan allt satt fast i den havererade SSD (som blev 'blank slate' att inte bcache heller kunde identifiera den eller återansluta och forcera en synkning i försök att få ut metadatat till snurrdisken och därmed rädda filsystemet) då default så flushar inte bcache mot disken förrän den börja bli väldigt full och då bara i småbitar i 4k-block efter block beroende på ålder och accesstäthet mm. - ingen periodisk synkning alltså då man förlitar sig på att SSD är pålitlig och är en del av disken sas. - nu finns det tusen kranar att justera i bcache så det går att få till periodisk flush/synkning om man vill - men det är inte default påslaget!

Även om man kör write-through i bcache så får man problemet nära lika snabb som writeback (typ under natten) men du räddar diskens filsystem och fungerar som en vanlig snurrdisk när SDD blivit utkickad av OS - dock är lite av syftet med SSD-cache borta när man inte längre kör writeback...

SSD:n (provat 3 olika märken - alla MLC-diskar, adata, liteon och samsung 830) och därmed ganska gamla och därför som jag tänkte få dem 'användbara' till något) var så tröga att skriva med slumpmässig data (för att inte vara komprimeringsbar data och forcera omskrivning av flash i SSD) att de hängde sig efter ett tag efter några tiotal GB och hastigheten låg i områden 10-tal MB/s i början till att tvärstoppa och ordagrant hängde sig...

Skrev man bara '0' med 'dd' så gick det bättre och man kom igenom hela disken utan hängning men fortfarande mycket långsamt i 2-siffiga antal MB/s och känns som en exponentiell förlopp inblandat bakom när det gäller diskens interna reallokering - förmodligen sökningen i trimtabellen som inte skalar väl när det börja spreta i alla riktningar - den disken som inte repade sig helt trots fler fulla 0-skrivningar och också med slumpvärden disken igenom och dummade sig med korta hängningar och andra microstopp var Samsung 830, den blev inte som innan igen förrän man hade gjort en security erase...

Senare på hemsidan hos 'bees' har det kommit upp not att bees inte fungerade så väl med just 'bcache' och att det berodde på olika SSD:s firmware om det blev ett problem eller inte.

Lärdomen - prova mycket och väl innan skarp användning - misshandla duktigt med skrivningar med olika stora blockstorlekar - kopiera över fulla hårddiskar med backupper, småfiler, stora mediafiler etc. och kör det tills stopp (ehum... ZFS kan bli väldigt slö om man kör det stumfull och det går ibland inte tillbaka även om man tömmer disken igen - en parameter att kolla och kryssa av i utvärdering - på samma sätt som att i NTFS inte krymper sin metadata igen efter 10-miljoner filtestet och helt plösligt har 11 GB död utrymme på disken som inte går att använda till något annat än just hålla tio miljoner väldigt små filer (< 300 - 400 byte styck) eller att ext4 på 80 GB-partition inte klarar 10 miljoner filer för att dess inoder tar slut långt innan dess

- i kamratens fall var problemen som han dök på inget som märktes till en början utan kom med tiden och användningen och kanske olika OS-generationer (under flera år)... därav att det var obehagligt när det väl inträffade, dock var mycket lagrat på molnet så det var ingen katastrof men oroande att detta kunde ske på något som räknas som långtids-arkiv/backup och därav användningen av redundant flerdisk diskpool...