Varför rapporterar en NAS ledigt utrymme men avvisar nya stora filer?

En NAS kan visa ledigt utrymme men ändå avvisa en stor fil när målets kvot, metadata, filgräns eller skrivbara allokering är uttömd.

Instrumentpanelen kan rapportera utrymme för hela lagringspoolen medan resursen tillhör en mindre datamängd, tunn volym, användarkvot, reserverat filsystem eller en nästan uttömd metadataprofil. En stor uppladdning kan också kräva tillfälligt utrymme, en andra kopia eller en filstorlek som målfilsystemet inte kan hantera. Börja med den exakta sökvägen och felkoden som misslyckas i stället för att anta att den övergripande siffran för ledigt utrymme beskriver hela åtgärden.

Identifiera vilket filsystem och vilken gräns resursen faktiskt använder

Översätt SMB-resursen eller programresursen till dess värdsökväg, monteringspunkt, datamängd, underordnade volym, tunna volym och underliggande pool. Anteckna lediga block, lediga inoder, användaridentitet och storleken på den avvisade filen.

GNU förklarar att df rapporterar det monterade filsystemet som är kopplat till en sökväg, inte alla pooler, kvoter, ögonblicksbilder eller begränsningar på programnivå ovanför och under det.

Om resursen skriver till en systempartition eller en mindre monterad datamängd är det lediga utrymmet i hela poolen irrelevant. Korrigera sökvägen eller monteringen innan du raderar data från fel lagringsnivå.

Kontrollera användar-, grupp-, datamängds- och resurskvoter

Jämför administratörens vy över ledigt utrymme med den kvot som gäller för den faktiska SMB-användaren, gruppen, datamängden, projektet eller den delade mappen. Testa med samma konto som får felet.

Oracle dokumenterar att ZFS kvoter och reservationer kan begränsa en datamängd även när oanvänt utrymme finns kvar i poolen eller reservera tillgänglig kapacitet för en annan datamängd.

Ta inte bort kvoter globalt. Höj endast den konstaterade begränsningen eller flytta filen till en datamängd vars kapacitetspolicy passar arbetsbelastningen.

Jämför datautrymme med metadata och arbetsutrymme för allokering

Kontrollera data, metadata, systemallokering, blockgrupper och filsystemsspecifika reservationsräknare. När en stor fil skapas kan det behövas metadatauppdateringar och arbetsutrymme för copy-on-write utöver nyttolastens byte.

Btrfs-dokumentationen påpekar att det kan returnera ENOSPC trots synligt ledigt utrymme när kraven på allokering och copy-on-write inte kan uppfyllas.

Om metadata är begränsade ska du använda filsystemets stödda diagnostik och begränsade återställningsåtgärder. Fyll inte det återstående utrymmet med ännu en stor testfil och starta inte en obevakad balansering utan att först mäta arbetsutrymmet.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Kontrollera inoder och gränser för filposter

Anteckna antalet lediga inoder eller filposter och räkna små filer i cachemappar, e-postarkiv, miniatyrbilder, extraherade paket och programkataloger. Stor bytekapacitet garanterar inte att ännu en katalogpost eller metadatafil kan allokeras.

Red Hats filsystemöversikt förklarar att XFS allokerar inoder dynamiskt och att filsystem har olika gränser för inoder och filposter.

Om inoderna är slut ska du ta bort eller arkivera en verifierad cache med många filer via programmet som äger den. Att radera en stor fil löser inte brist på filposter.

Verifiera målets maximala filstorlek och format

Identifiera målfilsystemet och jämför dess maximala filstorlek med den uppladdning som försöks göras. Ta med flyttbara mellanlagringsdiskar, USB-säkerhetskopieringsmål och programmets tillfälliga mappar.

Microsofts NTFS-översikt visar att den maximala filstorleken beror på filsystemets utformning och allokeringsparametrar, så ledigt utrymme totalt kan inte kringgå en gräns för en enskild fil.

Om felet inträffar nära en konsekvent gräns, till exempel 4 GB, ska du granska alla mellanliggande filsystem och hela uppladdningsvägen. En omformatering förstör data, så flytta verifierade filer till en annan plats innan du ändrar målformatet.

Mät krav på tillfälliga filer, glesa filer och förallokering

Kontrollera om uppladdaren skriver en tillfällig fil, förallokerar hela målet, behåller den gamla versionen tills filen byter namn eller packar upp ett arkiv till ytterligare filer. Mät den maximala allokeringen i stället för endast den slutliga filstorleken.

Systemanropet fallocate reserverar diskutrymme så att senare skrivningar inte misslyckas på grund av kapacitetsbrist, vilket innebär att ett program kan avvisa en stor fil innan alla data har överförts.

Välj en tillfällig katalog på den avsedda datapoolen eller inaktivera förallokering endast när programmet stöder det på ett säkert sätt. Behåll tillräckligt med marginal för originalet, den tillfälliga kopian, metadata och ögonblicksbilder under ersättningen.

Återskapa det exakta felet med en kontrollerad fil

Skapa testfiler under och över den storlek där felet uppstår, med samma användare, protokoll, sökväg och program. Fånga klientfelet och serverloggen utan att upprepade gånger försöka med produktionsfilen.

ZimaSpaces guide om hur man hittar oväntad utrymmesförbrukning på en NAS beskriver den kompletterande metoden för att jämföra synliga mappar med den faktiska allokeringen i filsystemet.

Problemet är löst när den bekräftade kvot-, metadata-, inode-, format- eller tillfälliga utrymmesbegränsningen har korrigerats och en fil som är större än den tidigare felgränsen kan skrivas, stängas, öppnas igen och verifieras utan problem. Avbryt skrivningar om filsystemet blir skrivskyddat eller rapporterar korruption eller maskinvarufel.