Att köra till stumfyllt filsystem är aldrig bra oavsett filsystem och en del filsystem kan behöva kunna skriva ny data innan det kan radera den äldre data och är det '0' ledigt lagringsutrymme så får man på dessa en read-only system där man inte kan göra något alls med detta¹. (framförallt COW-filsystem, även om de numera har liten inbyggd reserv för att kunna radera filer i alla fall när situationen uppkommer - NTFS har sin variant av det med dess begränsning av antalet fragment på en fil och speciellt när det gäller själva systemfilen som katalogiserar filnamnen i mappen att vid för många filer i mappen (som tex av indexering av stora fotoarkiv och skapa thumbnails av dessa och som jobbar i bakgrund) och det blivit fragmenterad för att det skrivits under lång tid - så blir det tvärstopp och heller inte kan ta bort filer ur mappen igen när det väl tagit stopp utan en massa trix - det var det som forcerade MS att desperat ta fram ReFS för att rädda kvar kunder när stora användare hamnade i dessa problem...)
Även 'mighty' ZFS mår jätteilla av det om man fyller över 80% och man kan över denna fyllnadsnivå - dock inte alltid, hamna i läge att filsystemets prestanda sjunker radikalt och det permanent då det hjälper inte att tömma filsystemet igen och ladda in data på nytt. Det enda man kan göra i det fallet är att skrota filsystemet och skapa en ny för att det skall bli sin forna prestanda igen.
Även ext4 och BTRFS tappar prestanda när man går över 80% och och börja märkas ordentligt när man passerat 90% fyllningsgrad när man har mogna system (filsystem där filer i olika storlekar har skrivit och tagits bort igen i många tusentals i antal).
Använder man filsystemet som en engångsskrivning som från nyformaterat bara fylla den med mediafiler från tom till full utan att under processen radera filer igen så kan man komma lite tätare mot när 100% fyllt innan upplevda problem.
på ext4 kan man reservera 5% (eller annan lägre procentsats) så att det fins lite reservutrymmer kvar för att åtgärda problem som root-user när man tex. fyllt filsystemet till stopp på användarsidan då smbd fortfarande kan skriva data mot /var/log-trädet liksom andra olika loggprocesser när dessa börja kräkas över stumfyllda filsystem... - men har man inte det...
teoretisk kan man också begränsa tillåten skrivmängd på användarnivå och gruppnivå - men på för många (fil)system så är detta lite för skakigt och dåligt provat med för många corner case kvar att fixa för att använda om man vill ha en problemfri serverdrift och fortsätta att vara en lazy admin...
¹ Exakt detta använder BTRFS för sina read-only snapshot - man sätter avsiktligt till att snapshoten har 0 byte ledig utrymme kvar och med detta kan inget inom snapshoten ändras då det måste skrivas först innan det kan radera något iom. COW-filsystem - inte dess egna metadata heller, vilket gör att allt inom snapshoten blir intakt inklusive all dess metadata och inoder, med tidstämplar etc.
