Misschien een rare vraag, maar wat is eigenlijk een map (of directory)?
Is dat ech een
fysieke locatie op de server (harde schijf) of is het eerder een soort database koppeling, tussen een map en een bestand zoiets als dit (even heel simplistisch):
Code (php)
1
2
3
4
5
6
7
8
9
// tabel directories
id name
1 home
5 public_html
// tabel files
id name dir
1 favicon.ico 5
2 index.php 5
Weet iemand dat toevallig?
Voor zover ik weet kan je een map rekenen tot een fysieke locatie. Tenzij het een symbolic-link in linux is. Dan is het een koppeling met een andere map.
Een map is eigenlijk gewoon een container. Zie het als een div in een html pagina.
- Aar - op 29/03/2013 17:41:15:Voor zover ik weet kan je een map rekenen tot een fysieke locatie.
Maar is het dat technisch ook echt?
Stel ik zou op een harde schijf het beginpunt en het eindpunt van de map public_html pakken... staan daar tussenin dan ook echt de bestanden die in die map staan?
Ik denk dat er tussen het begin en eind punt van een map alleen pointers naar de bytes met de bestanden staan, niet de echte bestanden.
Maar in dat geval is het toch een soort van "koppeling" dan?
Nog uit het DOS tijdperk, maar waarschijnlijk wel duidelijk genoeg.
http://nl.wikipedia.org/wiki/FAT16Dankjewel SanThe. Wel een nogal technisch verhaal. Maar als ik het goed begrijp werkt het dus wel met verwijzingen en niet met daadwerkelijk fysieke locaties.
Elk bestand dat groter is dan een blok/cluster of hoe het ook heet kan over de hele schijf verspreid liggen.
Toevoeging op 29/03/2013 19:50:07:
Dus heel veel bestandjes van 1 byte maken een schijf al snel vol.
- SanThe - op 29/03/2013 19:48:52:Dus heel veel bestandjes van 1 byte maken een schijf al snel vol.
Omdat?
Elk bestandje neemt minimaal 1 heel blok/cluster in beslag.
Dus 1 byte of het aantal bytes dat er in een heel blok/cluster past maakt geen verschil.
in werkelijkheid is het nog veel erger op je harde schijf. zelfs de inhoud van de bestanden hoeven niet aan één stuk te staan.
bijv.
cluster 1: eerste 512 bytes van bestand A
cluster 2: bestand B
cluster 3: volgende ? bytes van bestand A
En wat is dan precies een cluster... en als het allemaal door elkaar staat, is dat dan niet nadelig voor de preformance?
op een harde schijf kun je in theorie één lange sliert aan gegevens wegschrijven. stel nou dat een gebruiker tien bestanden op een harde schijf achter elkaar wegschrijft. De volgende dag is bestand nummer drie overbodig geworden en moet er tussen uit. we kunnen het bestand wissen maar er ontstaat dan een niet gebruikt gat tussen bestand twee en vier. als we een nieuw bestand toevoegen en we doen dit altijd aan het eind van de gegevens 'sliert' dan zal het gat nooit meer hergebruikt worden. En daarom heeft men in het DOS tijdperk bedacht om de sliert in vakken te delen die we dus clusters noemen. daarbij wordt dan per cluster bijgehouden of hij gebruikt is of niet. zo niet dan kan er weer in geschreven worden.
wat betreft de performance waar jij je natuurlijk weer druk over maakt :P :
je voelt m al.. clusters zijn sneller dan lange slierten verplaatsen om gaten te dichten.
Maar.. als bestanden na langdurig gebruik inderdaad in veel losse stukken op de harde schijf bij elkaar gezocht moeten worden dan kost dat ook wat extra tijd. daarom kun je je harde schijf onder windows zoals het zo mooi heet defragmenteren.
