Varför kan utökade attribut sakta ner filöverföring på NAS?

Utökade attribut kan sakta ner NAS-filmigration när bevarandet av dem lägger till upprepat metadataarbete för varje fil. Attributen är vanligtvis små, men ett migrationsverktyg kan ändå behöva upptäcka, läsa, mappa, överföra, återskapa och ibland verifiera dem. Över ett katalogträd med tusentals filer kan det arbetet per objekt bli synligt även när lite attributdata överförs över nätverket.

Nedgången i hastighet är villkorad. Stora mängder små filer är redan dyra att skapa och katalogisera, med eller utan xattrs. Protokollatens, kataloguppdateringar, behörigheter, indexering, lagrings-I/O och applikationsbeteende kan ge samma symptom. Utökade attribut bör därför mätas som en inkrementell migrationskostnad, inte antas vara den enda orsaken till att en NAS-kopiering är långsam.

Vad tillför ett utökat attribut vid en filkopiering?

En filkopiering innehåller normalt datainnehåll plus grundläggande metadata som storlek, tidsstämplar, ägarskap och behörigheter. Utökade attribut, ofta kallade xattrs, fäster ytterligare namn-värde-metadata till en fil eller katalog. Linux använder separata namnrymder för användardata, säkerhetsetiketter, betrodda attribut och systemobjekt som åtkomstkontrollistor. Linux-modellen för utökade attribut noterar också att filsystemets begränsningar kan skilja sig.

Bevarande kan kräva operationer utöver att kopiera datainnehållet. Ett verktyg kan lista attributnamn, hämta deras värden, avgöra om destinationen stödjer varje namnrymd och sedan sätta acceptabla värden på det nya objektet. Linux exponerar listning, läsning och skrivning via separata xattr-systemanrop. Det bevisar inte ett fast antal nätverksförfrågningar, men fastställer att attributhantering har en separat bearbetningsväg.

Den praktiska kostnaden beror på implementeringen. En klient kan cachelagra, köra i pipeline, kombinera eller hoppa över operationer, medan en server kan lagra ett attribut inline eller i en annan metadatastruktur. Den användbara skillnaden är mellan byte och objekt: ett attribut kan innehålla bara några få byte men ändå kräva ett beslut för varje fil som bär det.

Varför spelar antalet filer större roll än attributstorleken?

En fil på 50 GB är i huvudsak ett objekt med en lång dataström. Samma kapacitet uppdelad på foton, dokument, källfiler och paketträd kan innebära hundratusentals objekt. Varje destinationsobjekt måste skapas och läggas in i en katalog innan valfri metadata bevaras.

Detta skapar två lager av overhead. Basarbetet för små filer inkluderar att öppna filer, allokera poster, uppdatera kataloger, ställa in standardmetadata och stänga handtag. Xattr-bevarande kan lägga till attributuppräkning och återställning ovanpå. Om attributen kräver översättning eller en separat representation växer metadataflödet igen. Den sammanlagda tiden kan öka även om nätverket bär mycket lite extra attributdata.

Ingen universell förfrågningsmultiplikator följer av den mekanismen. Ett påstående som ”fyra förfrågningar per attribut” skulle kräva en paketspårning från exakt klient, protokollversion, överföringsverktyg och serverkonfiguration. Filer som slutförs per sekund och latens för metadataoperationer är därför mer användbara än att uppskatta resultatet enbart från attributstorlek.

När tillför protokoll- och filsystemsskillnader översättningsarbete?

Utökade attribut har ingen universell plattformsoberoende representation. Linux-filsystem exponerar xattr-namnrymder, Windows-filsystem kan exponera namngivna alternativa dataströmmar, och nätverksprotokoll definierar sina egna valfria funktioner. Microsoft dokumenterar stöd för alternativa dataströmmar som en filsystemsfunktion, medan NFSv4 definierar utökade attribut genom en valfri xattr-förlängning.

Ett migreringsverktyg måste välja vad det ska göra när dessa representationer inte stämmer överens. Det kan mappa en namngiven ström till en destinations-xattr, bevara endast stödda namnrymder, använda en privat kodning, skapa ett annat objekt eller utelämna metadata och rapportera ett fel. Sambas streams xattr-modul kan till exempel lagra SMB-alternativa dataströmmar i POSIX xattrs, men det är ett konfigurerat serverbeteende snarare än en regel för varje SMB-share.

Kompatibilitetsarbete kan påverka korrektheten även när dess prestandakostnad är liten. Ägarskap, ACL:er, säkerhetsetiketter eller applikationsmetadata kanske inte överlever en migrering som endast kopierar nyttolastdata. När problemet är förlorad åtkomst snarare än låg genomströmning, ger det separata arbetsflödet för behörighetsfel vid NAS-migrering den lämpliga felsökningsvägen; det är inte bevis på att xattrs orsakade fördröjningen.

När skapar AppleDouble extra metadataobjekt?

Mac-filer kan inkludera en datafork, resursfork, Finder-information och annan metadata. När en destination inte kan representera det kompletta objektet inbyggt, erbjuder AppleDouble ett två-objektsformat. AppleDouble-formatdefinitionen separerar den normala dataforken från en headerfil som kan bära resursforken och attributen.

Detta förklarar varför en migrering kan skapa ett följeslagande namn som en dot-underscore-fil, men det betyder inte att varje Mac-fil producerar en sådan. Ett ytterligare objekt är relevant endast när metadata behöver den representationen och programvaruvägen väljer AppleDouble. Moderna Samba-servrar kan också använda Mac SMB-metadata-moduler och bakande xattrs eller strömmar, så det exakta resultatet beror på klientbeteende, serverkonfiguration och filsystemets kapacitet.

Följeslagande objekt kan lägga till arbete för filskapande, katalog, uppslag, indexering och säkerhetskopiering. De garanterar inte att det totala antalet filer fördubblas eller att genomströmningen halveras. Plattformöverskridande anslutnings- och åtkomstfel är också en separat fråga; Windows och macOS SMB-kompatibilitet-arbetsflödet kan användas efter att metadata-mekanismen har förståtts.

Varför är inte varje långsam migrering ett Xattr-problem?

Stora träd med små filer är långsamma även när inga valfria attribut finns. Filskapning, kataloglåsning, behörighetskontroller, tidsstämplar, journalåtaganden, antivirusgenomsökningar, medieindexering, checksummor och applikationsnivåverifiering kan alla minska antalet filer som slutförs per sekund. HDD-sökbeteende eller synkrona metadatauppdateringar kan lägga till lagringslatens, men inget av detta bevisar att xattrs är orsaken.

Nätverket kan också se inaktivt ut medan klienten och servern väntar på objekt-nivåoperationer. Det mönstret är kompatibelt med xattr-arbete, men det är lika kompatibelt med vanlig filskapning, katalogkonflikter eller synkrona skrivningar. CPU-användning och råa megabyte per sekund är därför otillräckliga på egen hand.

Den renaste attribueringen är en kontrollerad jämförelse. Använd samma filuppsättning, källa, destination, protokoll, temperatur och lagringstillstånd, och jämför sedan en metadata-bevarande körning med en innehållsfokuserad körning som är känd för att utelämna valfria attribut. Skillnaden uppskattar den inkrementella bevarandekostnaden för den miljön; det blir inte en universell referens för en annan NAS-enhet.

Vad bör du mäta innan du ändrar metadata-policy?

Börja med datasettet. Räkna filer och kataloger, inspektera storleksfördelningen, identifiera hur många objekt som faktiskt har xattrs och registrera vilka namnrymder eller strömmtyper som förekommer. En migrering som innehåller några få attribuerade filer har en annan riskprofil än ett källträd där applikationsmetadata, ACL:er eller säkerhetsetiketter är brett fästa.

Mät framsteg både som byte per sekund och filer per sekund. Registrera förfluten tid, metadata-varningar, destinationsfel, protokollspår när de är tillgängliga, CPU-belastning, lagringslatens och förekomsten av följeslagarfiler. Detta skiljer en bandbreddsgräns för data från en gräns för objektbearbetning och visar om nedgången i hastighet ändras när attributbevarandet ändras.

Ta inte bort metadata bara för att ett test blir snabbare. Upstream rsync möjliggör bevarande av xattr med --xattrs eller -X, medan andra plattformar och äldre bundlade versioner kan använda olika alternativsemantik. rsync xattr-alternativen bör kontrolleras mot den installerade versionen. Eventuell prestandaförbättring måste vägas mot förlorade ACL:er, säkerhetskontext, Finder-information eller applikationstillstånd.

Vanliga frågor

Har varje NAS-fil utökade attribut?

Nej. Ett filsystem kan stödja xattrs utan att varje fil använder dem. Vissa filer bär användartaggar, ACL:er, säkerhetsetiketter, resursinformation eller applikationsmetadata, medan andra bara har vanligt filinnehåll och grundläggande metadata. Att inspektera källan är mer tillförlitligt än att anta att hela katalogträdet har attribut.

Varför är små filer långsamma när de inte har några xattrs?

Varje fil kräver fortfarande skapande, kataloguppdateringar, behörigheter, tidsstämplar, allokering och handtagsoperationer. Med tillräckligt många objekt dominerar dessa fasta kostnader överföringen av nyttolasten. Xattrs kan lägga till ett extra lager, men att ta bort dem kan inte eliminera den underliggande arbetsbelastningen för små filer.

Bevisar dot-underscore-filer att AppleDouble orsakade fördröjningen?

Nej. De indikerar att följeslagande metadataobjekt finns, vilket gör AppleDouble-relaterat arbete till en rimlig hypotes. De kvantifierar inte tiden som spenderas på dessa objekt eller utesluter indexering, skapande av basfil, lagringslatens och andra migrationskostnader.

Bevarar rsync utökade attribut som standard?

Inte i det generella upstream-beteendet. Bevarande av xattr kräver relevant alternativ, och stödda namnrymder beror fortfarande på privilegier och målfilsystem. Eftersom operativsystem kan leverera olika versioner av rsync, kontrollera den lokala manualen innan du tolkar -X, -E, eller arkivlägebeteende.

Skulle en övergång från SMB till NFS automatiskt lösa problemet?

Nej. Båda protokollen har implementeringsspecifikt metadata-beteende, och NFSv4:s stöd för xattr är valfritt. Val av protokoll involverar också behörigheter, klientkompatibilitet, låsning och arbetsbelastningsanpassning. Dessa bredare avvägningar hör hemma i den separata SMB versus NFS-jämförelsen, inte i en slutsats som bara gäller xattr-prestanda.

Slutsats

Utökade attribut kan sakta ner NAS-filöverföring när bevarandet kräver tillräckligt många läsningar, mappningar, skrivningar eller följeslagande objekt per fil för att bli betydande i stor skala. Bekräfta den inkrementella kostnaden med kontrollerade mätningar innan du ändrar metadata-policy, och ta med vanlig overhead för små filer, protokollbeteende, indexering, behörigheter och lagringslatens i diagnosen.