🚀 go-pugleaf

Stefan Arentz <stefan@keyser.soze.com> wrote:

> Dit is *precies* zoals vfat van Windows/DOS werkt. Ik snap niet waarom
> de tekst uit de FAQ niet van toepassing zou zijn op HFS/HFS+.

Er staat:

***
Je moet je harde schijf vergelijken met een soort rooster met allemaal
kleine gaten. Elk gat is een klein beetje ruimte op je schijf. Als er
een bestand binnenkomt, worden er -zeg, 15- gaten (achter elkaar)
opgevuld met dat bestand. Nu komen er steeds meer nieuwe bestanden en is
er een rijtje met opgevulde gaten. Nu gaan we het bestand van 15 gaten
weggooien. Er ontstaan dan 15 lege gaten. Het volgende bestand dat
binnenkomt is 16 gaten groot. De eerste 15 gaten van het bestand worden
in het gat gedaan. Maar het volgende gat is al vol door een ander
bestand! Dus gaat de schijf zoeken naar een ander leeg gat en wordt daar
het laatste gat van het bestand opgevuld.
Je ziet dus dat het bestand in twee�n gedeeld is.
***

Dat is gewoon niet waar. Het bestand raakt pas gefragmenteerd als het
met geen mogelijkheid meer aaneengesloten op de schijf past. 

Zelfs als bijvoorbeeld een voorkeuren bestand groter wordt en niet meer
in zijn orginele vakje past raakt het niet gefragmenteerd. Bij DOS wordt
namelijk het overloop gedeelte ergens anders geplaatst. Bij Mac OS is
het echter al jaren gewoonlijk om dan een compleet nieuw bestand te
schrijven waar weer een passend plekje voor wordt gezocht. Je moet onder
Mac OS apart moeite doen om een bestand te schrijven dat van te voren
geen bekende lengte heeft. 

Samen met de logaritmes van HSF en HSF+ zorgt dit ervoor dat in de
*praktijk* fragmentatie onder de paar procent blijft en daarmee geen
invloed op de snelheid heeft. Onder de voorwaarde dat er wat speelruimte
is natuurlijk en dat je die hele grote instromende bestanden als DV op
een apart volume opneemt.
-- 
Dennis SCP [nl,en,(de)]

The Apple G4 Cube.
The coolest toaster on the planet.