Kan man fylla en hårddisk med tomma mappar?

Permalänk
Bildexpert

Kan man fylla en hårddisk med tomma mappar?

Ja, som titeln säger undrar jag om det är möjligt? Någon data bör ju även tomma mappar ta upp då de behöver vara namngivna för att ens kunna hittas och således krävs utrymme.

Men förutsätt att man har en 1TB hårddisk (eller SSD), formaterad i NTFS, hur många mappar skulle då krävas tills den blir full? Om det är möjligt dvs.

Permalänk
Medlem
Skrivet av Nissling:

Ja, som titeln säger undrar jag om det är möjligt? Någon data bör ju även tomma mappar ta upp då de behöver vara namngivna för att ens kunna hittas och således krävs utrymme.

Men förutsätt att man har en 1TB hårddisk (eller SSD), formaterad i NTFS, hur många mappar skulle då krävas tills den blir full? Om det är möjligt dvs.

Nej det kan man inte. Platsen en tom mapp tar kan man bortse från. enligt Den här länken tar 1.000.000.000 tomma mappar drygt 7 gig.

Visa signatur

CPU: Ryzen 5600xGPU: 1080 TI ROG Strix RAM:2x16GB G.skill Trident @ 3600MHz MoBo: Asus B550FPSU: Corsair SF750
En resa till Nordkorea
2 dagar i Tjernobyl

Permalänk
Medlem

Prova med ett powershell script och randomiza namnet på nya mappen, så får du se En ide är ju att göra det på en icke-OS disk...

Permalänk
Medlem

Det är väldigt olika beroende på vilket filsystem som används. Det är inte så enkelt som att en katalog alltid tar upp lika mycket utrymme, eller att du kan skriva hårddisken full med bara kataloger på samma sätt som du kan skriva den full med filer. Kataloger hanteras i allmänhet på ett väldigt annorlunda sätt än filer.

Tycker du det är värt besväret så rekommenderar jag att du läser på lite whitepapers för de filsystem du är intresserad att få frågan besvarad för.

Visa signatur

Nu lurade jag dig att slösa bort ett par värdefulla sekunder av ditt liv på att läsa denna fullständigt poänglösa signatur!

Permalänk
Medlem
Skrivet av Nissling:

Ja, som titeln säger undrar jag om det är möjligt? Någon data bör ju även tomma mappar ta upp då de behöver vara namngivna för att ens kunna hittas och således krävs utrymme.

Men förutsätt att man har en 1TB hårddisk (eller SSD), formaterad i NTFS, hur många mappar skulle då krävas tills den blir full? Om det är möjligt dvs.

Windows presenterar inte vad mappen i sig tar upp för utrymme på disken utan hur mycket mappen innehåller vilket är 0 Bytes om den är tom. NTFS sparar förutom filnamnet även permissions till en mapp, flags, datum när mappen skapades och förändrades mm. Så om du antar att varje mapp har ett namn på 8 bokstäver där varje bokstav är en ascii bokstav och därmed tar upp 1 byte i utrymme blir detta ca 8 GB om du skapar 8 miljarder mappar. Så för att svara på din fråga så är svaret ja men antalet mappar du kan spara är aningen flexibelt då det beror på flera faktorer.

Permalänk
Medlem

Filsystem har alltid olika begränsningar och som utökats med tiden (tänk FAT, VFAT, NTFS) i tex. antal tecken i filnamn, hur många filer/direktorys som kan lagras i roten eller underdirektory etc.

NTFS har tex. ett tak på max antal filer vid 4,294,967,295 st per disk-volym (32-bitars räknare på inoder eller motsvarande filräknare uppenbarligen, det är sådana saker som skvallrar vilken tidsepok filsystemet skrevs i en gång i tiden och är närmast omöjligt att göra något åt senare eftersom det får konsekvenser precis överallt) och man kommer att slå i denna tak långt innan man fyllt med tomma filer/direktorys i en ordinär SSD-storlek på typiskt 240 GB.

Normal konsumentbruk så är det sällan man går över enstaka miljoner filer även på stora diskar som 8 TB, men det är klart, skall man ha lagringssystem i PByte-storlek med småfiler så finns det potentiellt tak för NTFS långt innan dess arktitektmässiga max-storlek är nådd och en av de grejorna som begränsar är just max antal filer filsystemet kan hantera.

Det här är dock aldrig ett reellt problem såvida inte dumma programvaror tex. lägger miljoner filer under samma direktory och då kan närma sig någon begränsning - men också söktiden inom direktoryt börja ta rejäl tid när det är enormt många filer.

Modernare filsystem än NTFS använder olika former av binära sökträn för att minska just söktider inom direktorys på snurrdiskar med enormt många filer i sig och ofta implementerad som en generell lösning för hela filsystemet då det också ingår strategier att lägga ut filerna på en smart sätt för att minimera fragmenteringen och hålla ned armrörelserna vid sökning och läsning på snurrdiskar - något som NTFS _inte_ är känt för... - ni som laddar ned och/eller hostar torrent, bör hitta en annan lösning av lagring som inte involverar NTFS på lagringsmedia, för det är att ta det sämsta av det sämsta när det gäller lagring på mekaniska diskar.

Det finns också andra begränsningar som hur många hårda länkar (dvs olika filnamn som refererar till samma inod och därmed datakropp - vanligt i Unix och används ofta i backupsammanhang för tex. daglig backup av ett filträd för att inte spara samma data flera gånger i filsystemet som separata kopior och ta upp plats, ett typiskt värde brukar vara max 10000 hårdlänkar per fil/inod.

---

slutligen:

Ni som ändå är nyfikna och vill prova att fylla en NTFS-disk med tomma filer och direktorys mha. olika scrip och program.

Gör det på en disk som ni kan partitionera och formatera om efteråt!!.

När man skriver en massa filstruktur i en NTFS-filsystem så är det en midgårdsorm som kallas $MFT som växer över disken (det är denna som lagrar alla filnamn med tillhörande attribut mm. och även mindre mängd data upp till ca 900 Byte per fil läggs direkt efter filnamnet och inte refereras ut till separat lagrings kluster - har man först lagrat säg 512 byte i en fil, stänger filen och sedan öppnar igen lägger till med data på filen så blir det fler sökningar vara första delen alltid måste letas i $MFT och sedan vidare ut över diskens lagringskluster för att plocka ihop filen till en komplett fil igen ) och den har den stora "finessen" att den försvinner inte eller kortas av när man tar bort alla sina filer igen och med den kvar så blir framtida inlagring av filer och data synnerligen ineffektiv när disken börja bli fylld - det är väldigt få och oftast kommersiella defragmenterings-programvaror som kan göra något åt detta, att i praktiken för att få disken snabb igen så är det bättre att formatera hela partitionen med en ny och fräsch NTFS - och det gäller alla NTFS-system som börja bli mer än tolerabelt långsam i sin filhantering och kör man torrent så når man den väggen ganska snabbt på mekaniska diskar - men även SSD påverkas så småningom med fruktansvärt stort antal små och ineffektiva anrop av små block istället för färre och större block i ett svep när det läses och skrivs.

Permalänk
Medlem

Lösning är att göra ett program eller skript som brute force börjar göra kataloger utav bara helvete, gör 500, gå ner i varje och gör 500 till, osv.

Det är klart att det går.

Visa signatur

|[●▪▪●]| #Lekburk#: Ryzen 3700X >-< GB-X570-AE >-< 32GB DDR4 >-< MSI RTX 3070 >-< 970 EVO 1TB SSD>--
--< Arctic Freezer 34 >-< FD Define R4 >-< Seasonic F.+ 650W >-< Acer XF270HUA >-< AOC Q2778VQE >--
#Servering#: Ryzen 1700@3,6GHz >-< Prime X470 Pro >-< 16GB DDR4 >-< GTX 1030 >-< 970 EVO 500GB SSD >--
--< Stockkylare >-< Antec P182 >-< Silver Power 600W >-< Samsung 245T |[●▪▪●]|

Permalänk
Medlem

Letar man lite så finns färdiga script att hitta med mer eller mindre avancerad grad - oftast bash/shell-sript och mindre ofta för windows power-shell.

Att göra tom fil på 0 byte gör man med tex. 'touch' i linux/unix-miljö och namnen med dum uppräkning eller om man vill ha lite längd på den - låta uppräkningen gå igenom SHA512 och man får hash-summan som namn.

vill man prova en ny NAS så vill man prova systemet (via ssh lokalt på nasen oftast) även med fyllda filer med olika längd med slump och köra tills diskarna tar stopp för att de är stumfyllda och se att det hanterar situationen bra - det gör köpeNAS:arna förvånansvärt ofta inte...