[NTFS]Compressed, hoeveel langzamer?

[MightyMauz]

Ik heb mijn disks gecomprimeerd, maar nou is mij vraag hoeveel langzamer het is? En vooral wat de trage factor is, is dat de CPU of het geheugen of de doorvoersnelheid van de HDD?
Ik heb namelijk wel ondervonden dat CloneCD alleen maar mislukte kopieen maakt, als ik de tempfile op 1 van mijn compressed disks zet. En ik heb maar een 12x brander (geen Burnproof ofzo). En ook op 8x wil hij het niet doen. Gelukkig heb ik ook nog 1 FAT32 disk. Nero heeft dit probleem niet. Gaat die beter met zijn buffers om ofzo?

[Verwijderd]

Dit is geen antwoord op je vraag, maar toch:

Jeuzes man waarom ga je in deze tijd nog disks zitten compressen?? Ik ken het wel van vroeger, in de tijd van 20MB HD-tjes,.......dan wilde je weleens wat extra's.. maar ik zie ook dat je 85G heb,... en je systeempje is best up-to-date... schijven kosten geen donder meer, de 80G versies zijn helemaal te koop voor een prikkie als je kijkt naar prijs per Gig..... dus koop er gewoon een 80 Gigger bij voor 100 euro ofzo. Die compressie maakt de boel volgens mij 2x zo traag en dan kan je inderdaad onderzettertjes verwachten. Tamelijk ongelovelijk dat iemand in deze tijd zich nog aan compressie van zijn hele schijf waagt.

[Verwijderd]

Ik zal wel antwoord geven op je vraag:

Een gecomprimeerde file is kleiner. Dus de tijd die je HD nodig heeft om en te lezen is korter. Da's dus winst.

Zo'n file moet wel uitgepakt worden. Dan kost tijd. Da's dus verlies.

Als je een trage disk hebt met een hele snelle CPU heb je winst (reden lijkt me obvious).

Als je een snelle disk hebt met een trage CPU verlies je erop.

Op een moderne PC zal je nauwelijks performance verlies voelen (let wel, voelen. Niet meten).

Vergeet niet dat decomprimeren je CPU meer kietelt als normaal. Dat is weer verlies.

[MeNTaL_TO]

Ik heb op mijn cursussen altijd te horen gekregen dat het nauwelijks impact heeft op je perfomance, en wel redelijk wat winst heeft. Hij pakt ook niet alles in, alleen vanaf een bepaalde compressieniveau.

[MightyMauz]

ALs het goed is, krijg ik volgende week ook een nieuwe schijf binnen. Een IBM GXP120 80 GB. Maar ik wilde het gewoon ff weten.
Voor die harde schijf moet ik geld overmaken naar een duits bedrijf, maar hoe de f**k vul ik zo'n overschrijvingskaart in?

[Pogostokje]

Voor die harde schijf moet ik geld overmaken naar een duits bedrijf, maar hoe de f**k vul ik zo'n overschrijvingskaart in?

Als ze geen nederlands banknummer hebben dan zal je een buitenlandse overboeking moeten maken. Een eurotransfer bijvoorbeeld. Dan heb je in ieder geval wat gegevens van de bank nodig waar het heenmoet (naam van de bank, adres van de bank en bankcode) en wat gegevens van het bedrijf waar het heenmoet. Ik zou zeggen: ga ff langs je bank voor wat uitleg.
Met een gewone overschrijving kan het niet.

[MightyMauz]

Op woensdag 26 juni 2002 07:56 schreef Pogostokje het volgende:

[..]

Met een gewone overschrijving kan het niet.

OK, dan weet ik dat ook weer Ik had ze al een overschrijvingskaart gemaild en daarbij uitleg gevraagd. Maar dan ga ik wel ff langs de bank.

[4POX]

Ik heb ook compressie lopen als een test. Niet omdat ik ruimte te kort heb. Maar omdat ik rond de 50.000 kleine files op die schijf heb staan. Normaal is het verlies wat ik dan heb door de cluster gigantisch. Maar door de compressie is het verlies nu maar 0%.. Het probleem is dat die files allemaal plaatjes zijn in verschillende catagoriën en dat het door die compressie superlang duurt om met irfanview thumbnails te maken. Terwijl dat normaal supersnel gaat.

Heeft iemand voor mij nog een oplossing om er voor te zorgen dat ik veel files kan bewaren zonder compressie en zonder verlies van cluster space ?

[Verwijderd]

Op woensdag 26 juni 2002 11:07 schreef 4POX het volgende:
Ik heb ook compressie lopen als een test. Niet omdat ik ruimte te kort heb. Maar omdat ik rond de 50.000 kleine files op die schijf heb staan. Normaal is het verlies wat ik dan heb door de cluster gigantisch. Maar door de compressie is het verlies nu maar 0%.. Het probleem is dat die files allemaal plaatjes zijn in verschillende catagoriën en dat het door die compressie superlang duurt om met irfanview thumbnails te maken. Terwijl dat normaal supersnel gaat.

Heeft iemand voor mij nog een oplossing om er voor te zorgen dat ik veel files kan bewaren zonder compressie en zonder verlies van cluster space ?

Zo klein mogelijke clustersize!

[Olaf van der Spek]

Op woensdag 26 juni 2002 11:07 schreef 4POX het volgende:
Ik heb ook compressie lopen als een test. Niet omdat ik ruimte te kort heb. Maar omdat ik rond de 50.000 kleine files op die schijf heb staan. Normaal is het verlies wat ik dan heb door de cluster gigantisch. Maar door de compressie is het verlies nu maar 0%..

Hoe heb je dat gecontroleerd?

[4POX]

Op woensdag 26 juni 2002 18:02 schreef OlafvdSpek het volgende:

[..]

Hoe heb je dat gecontroleerd?

Door met je rechtermuisknop op de map te klikken. En dan kun je de werkelijke grootte zien en de grootte op de schijf. En bij compressie zijn beide waarden nagenoeg gelijk.

[Olaf van der Spek]

Als ik een bestand van 4 byte inpak wordt er op schijf nog steeds 4 kb gebruikt hoor.

[MightyMauz]

Op donderdag 27 juni 2002 19:39 schreef OlafvdSpek het volgende:
Als ik een bestand van 4 byte inpak wordt er op schijf nog steeds 4 kb gebruikt hoor.

Dat wel jah, maar als jij 2 bestanden van 4 byte hebt, dan gebruikt dat 8kb. Maar als je het inpakt, gebruikt het nog maar 4 kb

[4POX]

Als w2k compressie werkt net zo werkt als de compressie bij drvspace en bij stacker, dan worden alleen gecomprimeerde bestanden allemaal in 1 groot bestand gegooit. Daar heb je bij compressie ook geen cluster verlies.

[sverzijl]

Op vrijdag 28 juni 2002 00:09 schreef 4POX het volgende:
Als w2k compressie werkt net zo werkt als de compressie bij drvspace en bij stacker, dan worden alleen gecomprimeerde bestanden allemaal in 1 groot bestand gegooit. Daar heb je bij compressie ook geen cluster verlies.

Het werkt niet hetzelfde als stacker/drvspace. Je kan namelijk ook per file aangeven of deze gecompressed moet worden of niet. Het is niet zo dat meteen het hele filesystem/disk compressed is. Het is dus feitelijk gewoon een extra layer in het fs.

[downtime]

Op donderdag 27 juni 2002 19:39 schreef OlafvdSpek het volgende:
Als ik een bestand van 4 byte inpak wordt er op schijf nog steeds 4 kb gebruikt hoor.

Bij NTFS niet... hele kleine bestanden krijgen bij NTFS niet hun eigen sectoren toegewezen maar worden gewoon in de MFT opgeslagen.

[downtime]

Op dinsdag 25 juni 2002 21:17 schreef Lord_Asswipe het volgende:
Ik heb namelijk wel ondervonden dat CloneCD alleen maar mislukte kopieen maakt, als ik de tempfile op 1 van mijn compressed disks zet. [...] Gelukkig heb ik ook nog 1 FAT32 disk.

Je kunt op die gecomprimeerde schijf ook een aparte folder aanmaken voor die tempfile. Zet het compressie-attribuut voor die folder gewoon uit en dan zal de tempfile voortaan niet meer gecomprimeerd worden, want nieuwe files erven de eigenschappen van de folder waar ze in aangemaakt worden.

[sverzijl]

Op vrijdag 28 juni 2002 00:20 schreef /downtime/ het volgende:

[..]

Bij NTFS niet... hele kleine bestanden krijgen bij NTFS niet hun eigen sectoren toegewezen maar worden gewoon in de MFT opgeslagen.

in de MFT wordt alleen metadata opgeslagen (filemapping), niet de files zelf.
Je kan natuurlijk wel je allocation unit op 512 bytes zetten ipv 4096(default bij schijven>2GB) als je wilt dat er minder slack optreedt.

[downtime]

Op vrijdag 28 juni 2002 00:25 schreef sverzijl het volgende:

in de MFT wordt alleen metadata opgeslagen (filemapping), niet de files zelf.
Je kan natuurlijk wel je allocation unit op 512 bytes zetten ipv 4096(default bij schijven>2GB) als je wilt dat er minder slack optreedt.

Dit vond ik op het volgende linkje:

Remember that under NTFS, there is no special distinction between the data in a file and the attributes that describe the file--the data itself is just the contents of the "data attribute". This has an interesting implication for small files. If the amount of space required for all of the attributes of a file, including the data it contains, is smaller than the size of the MFT record, the data attribute will be stored resident--within the MFT record itself. Thus, such files require no additional storage space on the volume, and also do not require separate accesses to the disk to check the MFT and then read the file, which improves performance.

[sverzijl]

Op vrijdag 28 juni 2002 00:36 schreef /downtime/ het volgende:

[..]

Dit vond ik op het volgende linkje:
[..]

ah. dat was nieuw voor me. toch nog wat geleerd vandaag.

Dat zou betekenen dat bij default allocation unit (4K) files van 3K nog gewoon binnen 1 MFT record kunnen worden opgeslagen (1 MFT record is zo'n 1024 bytes meen ik me te herinneren).

[edit]
maar wat boeit het eigenlijk ook met zulke grote HDs tegenwoordig. Ik heb toch nog maar +/- 500.000 files op mn schijf staan

[Olaf van der Spek]

Op vrijdag 28 juni 2002 01:05 schreef sverzijl het volgende:
Dat zou betekenen dat bij default allocation unit (4K) files van 3K nog gewoon binnen 1 MFT record kunnen worden opgeslagen (1 MFT record is zo'n 1024 bytes meen ik me te herinneren).
[edit]
maar wat boeit het eigenlijk ook met zulke grote HDs tegenwoordig. Ik heb toch nog maar +/- 500.000 files op mn schijf staan

Sinds wanneer past 3k binnen 1k?
En als je clusters van 32k zou hebben heb je met 500000 bestanden > 7 gb slack space. Dus het maakt toch echt wel wat uit welke clustersize je neemt.

[Olaf van der Spek]

Op vrijdag 28 juni 2002 00:20 schreef /downtime/ het volgende:

[..]

Bij NTFS niet... hele kleine bestanden krijgen bij NTFS niet hun eigen sectoren toegewezen maar worden gewoon in de MFT opgeslagen.

Dat bestand stond toch echt op een NTFS volume.

[Olaf van der Spek]

Op donderdag 27 juni 2002 20:16 schreef Lord_Asswipe het volgende:

[..]

Dat wel jah, maar als jij 2 bestanden van 4 byte hebt, dan gebruikt dat 8kb. Maar als je het inpakt, gebruikt het nog maar 4 kb

Dan wordt er vrolijk 8 kb gebruikt (als ik alle twee de bestanden selecter en alt-enter gebruik).

[mvdejong]

Op vrijdag 28 juni 2002 16:18 schreef OlafvdSpek het volgende:

[..]

Sinds wanneer past 3k binnen 1k?
En als je clusters van 32k zou hebben heb je met 500000 bestanden > 7 gb slack space. Dus het maakt toch echt wel wat uit welke clustersize je neemt.

Hij schreef het niet helemaal lekker op. De bedoeling is :
Allocation-unit 4 kByte, maximale MFT-record = 1 AU = 4 kByte.
Metadata in MFT-record 1 kByte.Ruimte voor "echte" data in MFT-record <= 3 kByte.

[Verwijderd]

Op woensdag 26 juni 2002 11:07 schreef 4POX het volgende:
... Maar omdat ik rond de 50.000 kleine files op die schijf heb staan. Normaal is het verlies wat ik dan heb door de cluster gigantisch. Maar door de compressie is het verlies nu maar 0%..

Heeft iemand voor mij nog een oplossing om er voor te zorgen dat ik veel files kan bewaren zonder compressie en zonder verlies van cluster space ?

Dat eerste snap ik niet... Cluster-waste wordt toch alleen maar meer als bestandjes kleiner worden (tenzij het zo is dat voor compressie een bestandje 1,0002 cluster in beslag neemt en 0,99 cluster na)

Ik zou die bestandjes op een aparte partitie bewaren en je clustergrootte optimaal kiezen. Zonder compressie natuurlijk.

[sverzijl]

Op vrijdag 28 juni 2002 16:18 schreef OlafvdSpek het volgende:

Sinds wanneer past 3k binnen 1k?

mja, t was al laat zullen we maar zeggen..maar je begrijpt het inmiddels?

En als je clusters van 32k zou hebben heb je met 500000 bestanden > 7 gb slack space. Dus het maakt toch echt wel wat uit welke clustersize je neemt.

Ja en als ik een clustersize van 64K gebruik dan heb ik nog meer slack. Zo ken ik er nog wel een paar.

In praktijk is er vrijwel niemand die afwijkt van de default clustersize.
(Ik durf te wedden dat 99% niet eens weet dat als je NT/Win2k installeert op een FAT drive en deze vervolgens laat converteren naar NTFS (CONVERT.EXE) je dan een clustersize van 512bytes krijgt en niet de default 4K die je krijgt als je een (lege) drive formatteert.)

[Verwijderd]

[Hier stond onzin.]

[Olaf van der Spek]

Op vrijdag 28 juni 2002 17:36 schreef sverzijl het volgende:
mja, t was al laat zullen we maar zeggen..maar je begrijpt het inmiddels?

Ja. Maar volgens PM7 is een file record 1 kb op een NTFS volume met 4 kb clusters op mijn systeem.

Ja en als ik een clustersize van 64K gebruik dan heb ik nog meer slack. Zo ken ik er nog wel een paar.

32 kb clusters kunnen best voorkomen hoor, vooral op een wat ouder systeem.

In praktijk is er vrijwel niemand die afwijkt van de default clustersize.
(Ik durf te wedden dat 99% niet eens weet dat als je NT/Win2k installeert op een FAT drive en deze vervolgens laat converteren naar NTFS (CONVERT.EXE) je dan een clustersize van 512bytes krijgt en niet de default 4K die je krijgt als je een (lege) drive formatteert.)

Wist ik ook niet. Bij mij is de cluster size trouwens 4 kb als ik met convert een FAT partitie converteer.

[MightyMauz]

Hmmmm, als mijn nieuwe harddiskje binnenkomt, toch alles maar weer uncompressen want het is nu zwaar traag. SiSoft Sandra resultaten:
C: 15.729 kb/s FAT32
D: 3.615 kb/s NTFS compressed
E: 2.808 kb/s NTFS compressed
F: 5,815 kb/s NTFS compressed
G: 11.321 kb/s NTFS compressed

En misschien dan ook alles maar weer naar FAT32 te zetten, want sommige dingen willen niet eens draaien op NTFS (16 bit blablabla error) o.a. Sandra setup en Memtest-86 setup.