Open Media Vault Samba share optimera prestanda för många små filer?

Efter att man insett hur fort man kan leta efter filer med 'find' och 'locate' direkt på servern (några sekunder med 'find' för 800000 filer och 150000 mappar) så är detta högst relevant fråga - egentligen skulle man vilja ha en klient-server roll som kan köra sökningarna på servern (med hänsyn till alla användarrättigheter i vad man får se och inte se) men presentera resultatet i klienten - närmast man kan komma nu är att SSH:a in till servern och köra 'find' eller 'locate' i terminal men det duger inte för alla utan det skall vara något klickbart typ, och helst integrerat i file-explorern sökfunktion för många.

idag suger sökmotorn i windows otroligt fast man söker på lokala filsystemet och att det ligger på NVMe-lagring verkar inte hjälpa. Det är inte kapaciteten på diskens IO som är bekymret utan allt annat som skall sniffa på datan medans det letar som windows-defender som jag upptäckte lätt kunde halvera antal filer i sekunden man vill söka och läsa i mappar...

till detta har vi NTFS - men om detta tar jag senare då jag just nu gör experiment med hur det fungerar med 10 miljoner småfiler i platt mapp och mapp med två nivåer mappar innan filen skrivs.

En sak kan jag säga redan nu om fler funderar i dom banorna - gör inte testerna på OS-systemdisken om du inte vill förlora lagringsplats permanent - ungefär 11 GB växer $MFT per 10 miljoner småfiler i NTFS-filsystem och det skriver ca 70 - 100 GB i fysiska sektoranrop mot lagringen (med sammanlagt ca 320 Mbyte data lagrad då var fil har 32 byte data) när dessa 10 miljoner filer skrivs (värdet taget från antal fysiskt skrivna sektorer på SSD:s SMART-data före och efter skrivtestet... - det totalt fullkomligt krigar med få-sektorsanrop på den stackars SSD medans småfilerna skrivs och verka knappt buffra eller samlar upp någon data alls i RAM-minne för mer sällan och större sekventiella skrivningar som moderna filsystem försöker få till så mycket det går) och det utrymmet lämnas _inte_ tillbaka som ledig diskplats igen när filerna sedan raderas

- file-entrys som tagits upp för att det är många filer är kvar i $MFT tills man skrotar filsystemet och formaterar om partitionen och denna utrymme kan bara återanvändas med att lagra massa småfiler igen med max ca 300 byte data per fil (så små filer att det inte krävs några externa sektorer allokeras i datadelen) - för större sammanhängande filer kan inte lediga utrymmet i $MFT användas.

Gör sådana experiment på egen SSD - ansluten via SATA och inte via USB-diskdocka om det skall bli klart innan Jul - Windows USB-transaktions-stack är inte att leka med när det gäller att käka CPU och söla ned varje diskanrop mycket kännbart - det är ingen problem i skrivfart mot USB när en större fil skall föras över till en USB-disk, men start och stopp för var transaktion vare sig det är en sektor stor eller flera tiotusentals sektorer som skall läsas/skrivas är dyra i tid och resursmässigt.

För att söka filer i windows förutom nätverksdisk/platser så använder jag Everything och du söker filer lika snabbt som du skriver.
Har inte använt windows egna sök på troligen 8-10år förutom när win8,1 och win10 installerades första gången och jag provade sök lite men kom fram till att det fortfarande var totalt oanvändbart.

Sen ang SMB så vet jag inte om nåt som kan hjälpa tyvärr, kanske kan finnas en lite skillnad mellan olika SMB/Samba versioner.
Det enda jag kan tänka mg kan hjälpa är ett annat filsystem på diskarna.

Tex en benchmark från denna tråd https://unix.stackexchange.com/questions/28756/what-is-the-mo...
Using Linux Kernel version 3.1.7
Btrfs:
create: 53 s
rewrite: 6 s
read sq: 4 s
read rn: 312 s
delete: 373 s

ext4:
create: 46 s
rewrite: 18 s
read sq: 29 s
read rn: 272 s
delete: 12 s

ReiserFS:
create: 62 s
rewrite: 321 s
read sq: 6 s
read rn: 246 s
delete: 41 s

XFS:
create: 68 s
rewrite: 430 s
read sq: 37 s
read rn: 367 s
delete: 36 s

Har för mig att jag även läste nånstans att XFS funkade bra till väldigt stora men få filer och var anledningen till att jag valde XFS till min unraid burk.

Tror inte filsystemet är den stora flaskhalsen om tex. metadatan och extensionträdet är defragmenterad i filsystemet (gäller BTRFS)

Eftersom jag gör 10-miljoners filers test och precis kört på ext4 med 2 nivåer filträd med 0xff (255) antal filmappar på varje nivå innan filen skrevs - med 'time find mapp -type f | wc -l' för att räkna antal filer så gick det på 5,054 sekunder reell tid, och detta inklusive att alla filnamn från find har tryckts igenom 'pipe' till wc för att räkna antalet filnamn som ord i textform. - nu skall sägas att all filsystemsmetadata var redan inladdad efter tidigare filläsnings-prov men om man klarar 10 miljoner filer på 5 sekunder så bör 500000 filer klaras av på ca 252 ms om metadatat för filsystemet är disk-cachat

Har inte exakt tittat hur SMB hanterar filnamnsförfrågningar och filliste-överföring fungerar, men gissar problemet finns där med väldigt många upphackade paket och därmed mycket overhead-tid i överföring mha. SMB-paket när en stor mapp skall listas - sedan skall också klientsidan också kunna hantera det och där finns begränsningar i hur många filer som kan visas under en och samma mapp och går långt in tidigare än reella begränsningar i filsystem.

Men Everything fuskar och bygger upp en egen index i förväg och därmed tar upp plats på disken i oftast användarens 'AppData' - över nätverksvolymer så kan den ställas in för indexering per dag eller timmar men är inget man vill ha i företag om dessa multipla laptop/datorer i 10 och kanske 100-tal oberoende av varandra skulle trasha servern med filnamnsförfrågningar för omindexering ala Everything hela tiden...

Med indexering i tidsperiod får man heller inte reda på nyinlaggda och ändrade filer innan nästa indexering körs. på lokala datorn har man sniff på när filer öppnas och stängs och den vägen kan hålla reda på nya filer kommer till - dessvärre är det också mycket annat som har sniff på filer som tex. ms defender som verkligen sölar ned filhanterandet när jag gjorde experiment med 10 miljoner filer på en SSD skulle säga dubbla den redan långsamma takten (i jämförelse med andra filsystem) när man skriver och tar bort filer...

Jag skulle helst vilja se en lösning med en förfrågan för filer över nätverksvolymer till en service som linux/unix 'locate' eller motsvarande i snygg förpackning för klientdatorerna - då räcker det med en indexering körs på servern - inte att alla skall köra varsina egna indexering i tid och otid och ge nätbelastningar och resursförbrukning på servern.

"Är verkligen en fildelning rätt verktyg för detta ändamål?", är den första fråga jag ställer mig. Utvecklar du ett nytt program skulle jag kolla på att lägga datat i en databas eller på bloblagring/key-value store istället för på ett SMB-share.

Tilläggas ska att om du vet vad du kollar efter och bara ber datorn hämta en fil med givet namn från en katalog istället för att enumerera hundratusentals objekt så kommer prestandan troligen vara helt OK för vardagsbruk även över SMB.

Jag håller med, stora mapplistningar med hundratusentals filer som skall föras över nätverk varenda gång när man skall leta fil i en filutforskare kommer att korka igen vilket system som helst och även ger trubbel på klientsidans program.

I Unix uppfann man 'xargs' för att stycka upp listor från tex. "find" i lagom portioner så att det inte översteg kommando-bufferstorleken på använda shellet och så körde den kommandot upprepande till listan är slut - då detta är inget nytt problem med enorma listor där mottagande delen inte har bufferstorlek för att kunna ta emot allt på en gång och det långt innan man började prata om data över nätverk....

Filsystem är ofta väldigt snabba att få fram en specifik fil om man anger sökvägen och fulla filnamnet och det är egentligen ingen tidsvinst för filer utfördelat i en hierarkisk mappträdstruktur efter någon regel (tex. med hashvärdet på namnet eller innehållet) eller en flat mapp med hundratusentals till miljoner filer i samma mapp (det går faktiskt snabbare för filsystemet att söka i flat mapp med alla filer i samma mapp än hierarkisk träd med flera undernivåer mappar innan filernas plats) då alla moderna filsystem använder olika former av binära träd när det gäller att hitta filnamn och tillhörande datadel. - tex. BTRFS står för i princip "Binary-TRee-File-System" och filsystemskapare har verkligen klurat på hur man skall skaffa fram en efterfrågad fil med komplett filnamn så fort som möjligt.

Även NTFS har binära trän men även detta har utvecklats med tiden och en ext4/BTRFS är 5-10 gånger snabbare att skriva och söka fram (små)filer räknat i antal per sekund än NTFS.

Detta nyligen testat både i Linux och windows10-miljö med en ruby-snurra, windows tar 3950.09 sekunder för att skriva 10 miljoner filer @ 32 byte styck i en enda mapp på en i övrigt tom och nyformaterad SSD-disk, i Linux med reverse engineerad NTFS-drivrutin gick det på 3470.90 sekunder - alltså lite snabbare än windows!, med ext4 gick samma 10 miljoner filer i samma ruby-snurra 384.94 sekunder och med BTRFS 377.34 sekunder - läsning av filer (direktadresserade filer med full sökväg) gick på NTFS_win10 3377.10 s, NTFS_linux 3200.29 s, ext4 764.13 s, BTRFS 433.85 sekunder... allt på samma dator och samma disk gamingdator med I7-propp och 16 GB RAM. I både linux och WIN10 så var själva drivrutinen för NTFS mättat och tog en kärna helt för sig själv (dock dolt i windows - dvs. syns inte i taskmanagern) och det verkar arbeta enkelttrådat medans RUBY-interpretern låg på 10-15% lastnivå. För testerna med ext4/BTRFS i Linux var däremot RUBY interpretern mättad till 100% och CPU-belastningen för ext4 och BTRFS var typ 15-25% - svårt att veta då det är multitrådat med 'kernel worker' som sprids ut på alla kärnor parallellt i perioder. Med detta kan man troligen anta att det går ännu mer fortare att läsa och skriva filerna mot ext4/BTRFS med program skrivna i C då det i testet uppenbarligen begränsades i skriv och lästakt av att RUBY-interpretern var 100% lastad i testerna

Detta gjordes mer än en gång och det förvånande var att NTFS var så långsam i jämförelse med Linux olika filsystem att det provades på flera datorer och noterbart var den otroliga skrivmängden mot disken fysiskt då det verka knappt buffra något alls i Windows och typ skrev om samma sektor i $MFT 8-10 gånger fysiskt på disk per fil, medans det buffrade i Linux och alla sektormodifieringar skedde i RAM och den 'slutliga versionen' av $MFT skrevs ut då och då på fysisk disk. Inte konstigt att SMR-diskar har det besvärligt med NTFS med på platsen omskrivningar hela tiden i $MFT och fyller upp SMR-diskens PMR-utrymme fort, efter att sett detta...

Det var nära 100 GByte data som skrevs fysiskt på SSD för 10 miljoner filer (taget på SMART för SSD) under windows medans det var typ 13 GB när det skrevs under linux (i stort sett storleken på $MFT efter 10 Miljoner filer) - Noterbart också att jag hade gjort undantag för SSD med filsystem i windows defender då det annars hade tagit ytterligare dubbla tiden för läsning och skrivning i windows (första körningen med 10 miljoner filer tog över 7000 sekunder att jag knappt trodde mina ögon med tanke på att man klarade samma övning på under 400 sekunder i linux, och då såg att defender hoggade en massa CPU och hade disktrafik på samma nivå som mot $MFT och insåg kopplingen...)

---

Däremot har det jättebetydelse om man med filutforskaren råka klicka ned i en mapp med hundratusentals filer och får titta på den snurrande timglaset i mycket lång stund och det kanske tom. kraschar eller gör timeout i jämförelse att dessa hundratusentals filer är nedsorterat i en mappträd med max några hundra objekt per nivå så att det bara är 10-1000 filer per mapp längst ned som överförs när man söker runt med filutforskaren.

Så frågan är - hur frågar TS efter filerna, för människa via en fil-utforkare söker och letar efter en viss fil med olika sökbegrepp eller en program som begär en fil som den redan vet eller kan med regler räkna ut namnet på ??