[C]win vs linux aanmaken van meer dan 65532 files

[Verwijderd]

Voor een schoolopdrachtje moesten we een filesplitter maken en daarbij ben ik op het volgende gestoten. Mijn filesplitter werkt correct eveneens het aaneenvoegen echter ik merk een eigenaardigheid.
In windows had ik me mistypt en files van 2 bytes groot aangemaakt, nu was de file die ik wou splitten ongeveer 500kiB groot waardoor mijn programma 256 000 files wou aanmaken. Ik laat mijn pc wat rekenen en na een groot aantal minuten zie ik dat hij blijft steken bij 65 532 files. En windows (in mijn geval windows 2000) geeft een memory error. Na debugging constateer ik dat de stapelpointer (register esp) wijst naar adres 0x0000 0000 en een file wil schrijven op plaats 0x0000 0004
De esp wijst vervolgens naar het goede adres 0x0000 0004 maar op het moment dat hij daar enige bits wil schrijven (op dat adres) gaat het helemaal fout. Zoiets had ik uiteraard vermoed want mij lijkt het dat windows enige kritische informatie op de beginadressen van het geheugen heeft staan en dus niet wil dat die daar komen.
Allemaal goed en wel, maar ik wou dat toch even nader onderzoeken. Dus schreef ik gewoon een ander programma dat weer m.b.h.v. fopen() en file aanmaakt om te schrijven en dan het putc() daarin een (random) karakter steekt. Ik schrijf een kort lusje dat meer dan 65 532 laat schrijven en uiteraard sluit ik iedere file met fclose() na het schrijven van het karakter.
Ik compileer voer uit en pats na enkele minuten weer prijs, weer na 65 532 files, weer dezelfde foutmelding en weer betreffende dezelfde adressen.
Nu programmeer ik mooi volgens de ANSI-C standaard dus zeg ik bij mezelf waarom niet vlug even compileren en uitvoeren in linux (redhat 9.0 in mijn geval). Zo gezegd zo gedaan en tot mijn verbazing slaagt mijn programma er daar wel in om meer dan 65 532 files te schrijven (heb het voor 70 000 files getest).
Vervolgens test ik mijn splitter ook op files van een paar MiB's groot en ook hier slaagt hij erin te splitten in het correct aantal files.

Nu vraag ik mij toch een aantal dingen af, waarom zijn er problemen in windows en in linux niet? Kan het bijvoorbeeld zijn dat windows het geheugen slecht beheerd en dat door een bug bijvoorbeeld in windows een slecht stuk geheugen gealloceerd wordt door een willekeurig programma, waardoor windows uiteraard tegenstribbeld en een error geeft.
Of mijn ander vermoeden was dat windows minder geheugen reserveerd voor consoleprogramma's dan linux waardoor mijn programma in de problemen komt. Alhoewel ik het geheugen nogtans telkens weer vrijgeef. Ik sluit de files proper af, heb het programma zelfs gecompileerd onder de strengste voorwaarden (zonder memory leaks e.d.) dus ik zie niet in waarom windows meer geheugen zo nodig hebben dan linux voor mijn programma.

Ik wist het niet goed plaatsen want het kan uiteraard altijd een programmeerfout zijn (ik ben niet heilig natuurlijk) maar het kan natuurlijk ook iets eigen zijn aan fopen() en fclose() dat daar iets fout loopt waardoor windows foute adressen moet alloceren of wathever (bvb een fout bij de omzetting van die commando's naar machinetaal door de compiler, al lijkt me dat toch onwaarschijnlijk gezien het aantal jaren dat die compilers getest en gebruikt zijn).

Als compiler gebruik ik in windows Visual studio .NET 6.0 en op school de Visual Studio .NET 2003 en in linux gewoon cc

[-FoX-]

Ik dacht ergens gelezen te hebben dat windows per map maar 65 532 files toelaat..

Hoe/Waarom weet ik ook niet meer juist, is al een hele tijd geleden ondertussen

[Sjaaky]

Idd,
zie hier voor limieten van diverse ms filesystems.
fat32 heeft een limiet van 2^16 bestanden in een directory. ntfs gaat tot 2^32.

[Verwijderd]

Sjaaky schreef op 15 maart 2004 @ 11:27:
Idd,
zie hier voor limieten van diverse ms filesystems.
fat32 heeft een limiet van 2^16 bestanden in een directory. ntfs gaat tot 2^32.

Dit brengt me heel wat verder Lijkt me dat ik tegen de 65534 zit.

Rest mij nog uit te zoeken waarom hij precies na dat aantal files naar die plaats in het geheugen wijst waarop dan een fout volgt.

Maar bedant voor de info. En meer is altijd welkom, maar ik weet gelukkig al in welke richting ik moet zoeken.

edit: foutje

[ Voor 30% gewijzigd door Verwijderd op 15-03-2004 11:36 ]

[SimplyMe]

dus als ik sjaak zijn linkje lees dan moet je bij
65533 files een nieuwe folder aan maken en daarin verder gaan.
anders loopt windows dus gewoon vast

code:

FAT32
Maximum number of files and subfolders within a single folder 
65,534 (The use of long file names can significantly reduce the 
number of available files and subfolders within a folder.)

[xerix]

SimplyMe schreef op 15 maart 2004 @ 11:33:
dus als ik sjaak zijn linkje lees dan moet je bij
65533 files een nieuwe folder aan maken en daarin verder gaan.
anders loopt windows dus gewoon vast

Windows loopt niet vast, je krijgt gewoon een ongeldige file pointer terug. En ja, als je als programmeur niet checked of je filepointer wel geldig is, dan ga je schrijven op positie NULL ja.

[ Voor 3% gewijzigd door xerix op 15-03-2004 12:02 ]

[Maasluip]

Verwijderd schreef op 15 maart 2004 @ 11:32:
[...]


Dit brengt me heel wat verder Lijkt me dat ik tegen de 65534 zit.

Rest mij nog uit te zoeken waarom hij precies na dat aantal files naar die plaats in het geheugen wijst waarop dan een fout volgt.

Maar bedant voor de info. En meer is altijd welkom, maar ik weet gelukkig al in welke richting ik moet zoeken.

edit: foutje

Ik neem aan dat de . en .. directory ook als file gerekend worden. Met 65532 files en twee verplichte directories zit je dus aan de limiet.
Ofwel: limitatie van je filesysteem.

[Verwijderd]

xerix schreef op 15 maart 2004 @ 12:01:
Windows loopt niet vast, je krijgt gewoon een ongeldige file pointer terug. En ja, als je als programmeur niet checked of je filepointer wel geldig is, dan ga je schrijven op positie NULL ja.

Yep dat is waar, windows loopt niet vast, geeft enkel een foutmelding weer. En vermijden dat het programma niet correct stopt kan idd door de ofp te controleren. Maar dat is natuurlijk wel geen oplossing voor het probleem, het wordt blijkbaar tijd dat ze eens werk maken van FAT64 dan ofzo, want die NTFS is allemaal goed en wel maar dan moeten ze wel vrijgeven hoe het bestandssysteem ineen zit zodat men stabiel platformonafhankelijk kan schrijven naar NTFS. Kortom een nieuw bestandssysteem (met minder beperkingen qua aantal files, bestandsbenaming etc...) dringt zich op. Nouja dat is een compleet andere discussie.

Maasluip schreef op 15 maart 2004 @ 12:08:
[...]

Ik neem aan dat de . en .. directory ook als file gerekend worden. Met 65532 files en twee verplichte directories zit je dus aan de limiet.
Ofwel: limitatie van je filesysteem.

Mja of één van de twee, want het programma zelf (ook één file) zat in dezelfde map (wat neerkomt op 65533 files)

[ Voor 20% gewijzigd door Verwijderd op 15-03-2004 12:17 ]

[Maasluip]

Verwijderd schreef op 15 maart 2004 @ 12:15:
[...]

Yep dat is waar, windows loopt niet vast, geeft enkel een foutmelding weer. En vermijden dat het programma niet correct stopt kan idd door de ofp te controleren. Maar dat is natuurlijk wel geen oplossing voor het probleem, het wordt blijkbaar tijd dat ze eens werk maken van FAT64 dan ofzo, want die NTFS is allemaal goed en wel maar dan moeten ze wel vrijgeven hoe het bestandssysteem ineen zit

Blijkbaar heb je geen NTFS maar FAT16 of FAT32, want NTFS kan 2^32 - 1 files per volume aan. Nu is volume /= folder, maar in dezelfde link van [rml]Sjaaky in "[ C]win vs linux aanmaken van meer dan 65..."[/rml] staat dat als je 'use large numbers of files in an NTFS folder (300,000 or more)', dus in die regio moet je wel komen.

Als je wel NTFS hebt is er iets anders aan de hand.

Verder is het dus wel gedocumenteerd wat de limiten zijn.

[Verwijderd]

Maasluip schreef op 15 maart 2004 @ 12:31:
Blijkbaar heb je geen NTFS maar FAT16 of FAT32, want NTFS kan 2^32 - 1 files per volume aan.

Zover waren we ondertussen wel al NTFS gebruik ik zowiso niet thuis aangezien ik vanuit linux daar niet op kan schrijven (allé het gaat wel maar het wordt niet gegarandeerd dat alles wel goed loopt).

trouwens in diezelfde link staat:

Maximum number of files and subfolders within a single folder 65,534 (The use of long file names can significantly reduce the number of available files and subfolders within a folder.)

Aangezien ik korte namen heb gebruikt en alles mooi in 1 map staat heb ik 65532 files + 1 executable file + 1 map = 65534 wat juist de limiet is. Dus die limietwaarde klopt. 't enige wat dus rest is eigenlijk het onderzoeken met welke reden men die beperking had en dat bijvoorbeeld bij ext2 en NTFS anders is. 't wordt tijd dat ze eens werk maken van FAT64 misschien dan vaneens een bestandssysteem zonder fragmentatieproblemen
Maar dat hoort eigenlijk niet meer in dit topic.

[NMe]

Waarom zou je FAT64 willen als NTFS er al is? Het lijkt mij dat MS best tevreden is met het NTFS systeem zoals het is, en de behoefte aan nog een systeem lijkt er niet te zijn. En dat je NTFS niet optimaal kan gebruiken in Linux zal hun niets interesseren, komt alleen maar goed uit... Als je meer dan 65k bestanden wil maken zul je, als je echt niet wil overstappen op NTFS, gewoon verschillende mappen moeten maken... Wordt alleen leuk als je 65k mappen nodig hebt...

[Sjaaky]

Zijn er geen goede ext2/ext3 drivers voor windows die je kan gebruiken?

Onderzoeken waarom ze ooit besloten hebben een limiet van 65534 bestanden aan te houden lijkt me niet echt interessant. Dat zal wel neerkomen op het feit dat een 16bit waarde 2x zo klein is als een 32bit waarde en dus efficiënter. Er zullen weinig "huis, tuin en keuken"-gebruikers zijn die meer dat 65534 bestanden in 1 dir willen zetten. Bovendien zijn er makkelijke manieren om er omheen te werken zoals al eerder is besproken.

[ATS]

Ik kan me niet aan de indruk onttrekken dat het ook niet echt efficiënt is om 2^16 bestanden in één directory te zetten. Ik weet niet precies hoe FAT in elkaar zit, maar ik kan me niet voorstellen dat FAT daar snel in kan zoeken.

[curry684]

Verwijderd schreef op 15 maart 2004 @ 12:15:
[...]
Yep dat is waar, windows loopt niet vast, geeft enkel een foutmelding weer. En vermijden dat het programma niet correct stopt kan idd door de ofp te controleren. Maar dat is natuurlijk wel geen oplossing voor het probleem, het wordt blijkbaar tijd dat ze eens werk maken van FAT64 dan ofzo, want die NTFS is allemaal goed en wel maar dan moeten ze wel vrijgeven hoe het bestandssysteem ineen zit zodat men stabiel platformonafhankelijk kan schrijven naar NTFS. Kortom een nieuw bestandssysteem (met minder beperkingen qua aantal files, bestandsbenaming etc...) dringt zich op. Nouja dat is een compleet andere discussie.

Een compleet nutteloze discussie ook. Jij kiest ervoor op een deprecated obsolete filesysteem te draaien, terwijl alle hedendaags gangbare OS'en standaard met NTFS werken, een veruit superieur FS boven FAT32. En zoals gezegd staat netjes bedocumenteerd dat het FAT32 systeem dat ondertussen al ruim 10 jaar oud is inderdaad een relatief kleine limiet heeft op het aantal files per folder.

Voor NMe84: zelfs NTFS as we know it gaat binnen nu en 2 jaar uit de roulatie, want binnen Longhorn gaat NTFS enkel nog als onzichtbare onderlaag fungeren voor WinFS (Windows Future Filesystem) wat compleet database/index gestuurd is, en dus ook direct ATS' probleem oplost met dat accesstimes op een dermate grote dir rampzalig traag zijn.

Algemene procedure in dit soort gevallen is om directories aan te maken met de eerste letter als naam, dan verlaag je de searchtimes dramatisch. Desnoods kun je dit 2-laags doen zelfs (dus file pietje.gif komt dan in C:\...\mycache\p\i\pietje.gif)

=[edit]=

Ik zie trouwens dat je Win2k gebruikt... wtf doe je dan in godesnaam met een FAT32 schijf? NTFS is sneller, veiliger en bevat native security. FAT32 is een hobby-FS voor thuisgebruikers met een 486 en Windows 95 voor de spelletjes....

[ Voor 29% gewijzigd door curry684 op 15-03-2004 13:21 ]

[Verwijderd]

Onderzoeken waarom ze ooit besloten hebben een limiet van 65534 bestanden aan te houden lijkt me niet echt interessant.

Mij wel, het moet toch een reden hebben anders gaan ze dat niet doen (alhoewel). Waarom zou men anders in godsnaam beperkingen geven aan een bestandssysteem idem met bestandsnaam tekens die zijn ook veel meer beperkt op FATxx en NTFS-systemen. En uiteraard is dat onderzoeken misschien niet praktisch interessant nee, althans toch niet gezien vanuit het oogpunt van een programmeur.
Maar het bestuderen van limieten is zowiso interessant, want het is meestal daar dat er onvoorspelbaar gedrag is en waar onvoorspelbaar gedrag is gebeuren er fouten en fouten kosten geld en zelfs levens (cfr unsafe type cast bij Ariane 5 (veel geld) en patriot missile system failure (unsafe precision lost) welke 28 mensenlevens kostte).
Uiteraard is dit hier minder van belang immers de "fout" of "limiet"-waarde is goed gedocumenteerd (wat ik dus niet wist maar dankzij jullie te weten ben gekomen) al is er wel een zekere mate van onvoorspelbaarheid immers op een ander FAT-systeem werd het programma wel goed afgebroken (return 0) niettegenstaande het programma-verloop incorrect verliep (bij 65532 files is het programma immers gestopt met schrijven). Wat natuurlijk een fout is van mij want ik had idd mijn ofp niet gecontroleerd.
Enfin jah allemaal interessante dingetjes dus om naar te kijken

Er zullen weinig "huis, tuin en keuken"-gebruikers zijn die meer dat 65534 bestanden in 1 dir willen zetten. Bovendien zijn er makkelijke manieren om er omheen te werken zoals al eerder is besproken.

Dat is natuurlijk wel waar, maar daar gaat het mij niet om. Tenslotte is het mijn doel ook niet om 65534 files te schrijven. Ik vond dat alleen merkwaardig dat dat niet ging toen ik erop stuitte, dat heeft mij nieuwsgierig gemaakt.

Waarom zou je FAT64 willen als NTFS er al is? Het lijkt mij dat MS best tevreden is met het NTFS systeem zoals het is, en de behoefte aan nog een systeem lijkt er niet te zijn. En dat je NTFS niet optimaal kan gebruiken in Linux zal hun niets interesseren, komt alleen maar goed uit...

En daar wringt natuurlijk het schoentje, al is dit een andere discussie. Maar eigenlijk wel een voze tactiek van MS. Alhoewel, heel erg is het ook niet, die ext-systemen hebben immers minder mankementen dan die bestandssystemen van MS zoals fragmentatie bvb...

Als je meer dan 65k bestanden wil maken zul je, als je echt niet wil overstappen op NTFS, gewoon verschillende mappen moeten maken... Wordt alleen leuk als je 65k mappen nodig hebt...

ja, maar... ik wil dat niet hoor jullie bekijken het een beetje te veel praktisch gericht en omzeilen enz... Als programmeur is dat misschien allemaal niet interessant maar ik studeer dan ook niet voor programmeur.
Enfin jah, de constatering heeft mij eens doen kijken naar de verschillende bestandssystemen. Ik ga mij dan toch eens bezighouden met het uitzoeken waarom die verschillen er zijn, waarom er bijvoorbeeld fragmentatieproblemen zijn op FAT-bestandssystemen en geen op EXT en natuurlijk alle andere problemen.

Een compleet nutteloze discussie ook. Jij kiest ervoor op een deprecated obsolete filesysteem te draaien, terwijl alle hedendaags gangbare OS'en standaard met NTFS werken, een veruit superieur FS boven FAT32. En zoals gezegd staat netjes bedocumenteerd dat het FAT32 systeem dat ondertussen al ruim 10 jaar oud is inderdaad een relatief kleine limiet heeft op het aantal files per folder.

NTFS mag dan wel superieur zijn aan FAT32 maar dat is het zeker niet aan ext3. Verder zou het eigenlijk beter zijn moest men één goed bestandssysteem ontwikkelen dat iedereen gebruikt dan is er niets verwarring meer mogelijk en geen beperkingen bij de ene die anders zijn dan bij de ander.

Algemene procedure in dit soort gevallen is om directories aan te maken met de eerste letter als naam, dan verlaag je de searchtimes dramatisch. Desnoods kun je dit 2-laags doen zelfs (dus file pietje.gif komt dan in C:\...\mycache\p\i\pietje.gif)

Dat is een goed idee, maar zoals reeds gezegd en valt af te leiden uit de context gaat het mij niet echt om het schrijven van xxxxxxxx-hoeveelheden files. Dat was een ongelukje die aanzette tot denken.

Ik kan me niet aan de indruk onttrekken dat het ook niet echt efficiënt is om 2^16 bestanden in één directory te zetten. Ik weet niet precies hoe FAT in elkaar zit, maar ik kan me niet voorstellen dat FAT daar snel in kan zoeken.

Zie hierboven, en idd FAT kan daar niet erg snel in zoeken, ook het aanmaken gaat erg traag, ongeveer 20 keer trager als op de ext2 partitie die ik gebruikte. Precieze tijden kan ik opmeten voor geïnteresseerden, natuurlijk spelen andere zaken ook een rol, welke compiler het beste optimaliseerd etc...
Nouja het openen van de map met 65532 (FAT32) en 70 000 (ext2) duurde bij de één ook veel langer dan bij de ander evenals het deleten van de losse files. Hmmm misschien kan ik eens op een NTFS-systeem ook aanmaken en dan kan ik de drie vergelijken. Nuja er bestaan daar wss wel andere tests voor.

[ Voor 28% gewijzigd door Verwijderd op 15-03-2004 13:31 ]

[curry684]

pikachuf: als je jezelf goed wil informeren, doe dan ook je research voordat je loze opmerkingen gaat roepen. Zowel Ext2 als Ext3 dienen net zoals NTFS, FAT16 en FAT32 gedefragmenteerd te worden, leert 1 minuut research me.

Sowieso kun je hoogstens de overhead verplaatsen, niet uitroeien.: een filesysteem fragmenteert per definitie. Je kunt wel met slimme algoritmes trachten om voor nieuwe files 'best-fit' locaties op te zoeken ipv een willekeurig blok te pakken, en daarmee stel je fragmentatie een eind uit. Tevens kun je dit op runtime doen bij deletes bijvoorbeeld. Maar: je herverdeelt enkel de rekentijd. FATxx zijn gebouwd op snelheid en mochten dus niet die overhead doorlopend vertonen, vandaar dat ze er op zijn gericht om regelmatig gedefragged te worden. Er zat ook niet voor niets in 95/98 en ME wel een native defrag-optie en in WinNT4 niet (was zelden nodig kan ik uit ervaring melden).

[Sjaaky]

NOFI Studeer je geschiedenis?

Nee ff zonder dollen, die limieten zijn er omdat er het veel makkelijker is om een fs te implementeren met limieten dan zonder enige limieten. Ook is het vaak efficiënter (in ruimte en tijd) om limieten aan te brengen. Deze limieten worden vaak zo gekozen dat je er in de praktijk geen last van zult hebben. Uiteindelijk zijn het keuzes/afwegingen die gemaakt moeten worden. Het probleem is dat de keuzes die ze toen maakten op om een filesystem te ontwerpen nu achterhaalt zijn. In het geval van FAT waren de keuzes die ze op dat moment namen zelfs al achterhaalt. Op wikipedia is wat historie te vinden van diverse fs'en.

edit:

Het onderzoeken waarom bepaalde limieten bestaan en de afwegingen die daar bij komen kijken is imho alleen interessant als je zelf een fs wilt gaan ontwerpen

[ Voor 13% gewijzigd door Sjaaky op 15-03-2004 13:43 ]

[Verwijderd]

curry684 schreef op 15 maart 2004 @ 13:30:
pikachuf: als je jezelf goed wil informeren, doe dan ook je research voordat je loze opmerkingen gaat roepen. Zowel Ext2 als Ext3 dienen net zoals NTFS, FAT16 en FAT32 gedefragmenteerd te worden, leert 1 minuut research me.

Het gaat er dan ook niet om of ze gedefragmenteerd moeten worden maar hoeveel. Of net zoals je zegt in de volgende quote

Sowieso kun je hoogstens de overhead verplaatsen, niet uitroeien.: een filesysteem fragmenteert per definitie. Je kunt wel met slimme algoritmes trachten om voor nieuwe files 'best-fit' locaties op te zoeken ipv een willekeurig blok te pakken, en daarmee stel je fragmentatie een eind uit. Tevens kun je dit op runtime doen bij deletes bijvoorbeeld.

Iets wat bij de één dus duidelijker beter lukt dan bij de ander.

En mijn research was misschien idd niet zo goed, ben er nog volop mee bezig hé, eerst gezocht op GoT zie bvb:

Met een echt OS, komt meestal ook een echt filesystem, en echte filesystems hoef je bij mijn weten niet te defragmenteren. (ze zijn er niet, omdat je ze niet nodig hebt dus, vandaar dat je ze niet kan vinden).

blaataaps in [rml][ n00b] Defragmentatie?[/rml]

NOFI Studeer je geschiedenis?

Zoiets

Nee ff zonder dollen, die limieten zijn er omdat er het veel makkelijker is om een fs te implementeren met limieten dan zonder enige limieten. Ook is het vaak efficiënter (in ruimte en tijd) om limieten aan te brengen. Deze limieten worden vaak zo gekozen dat je er in de praktijk geen last van zult hebben. Uiteindelijk zijn het keuzes/afwegingen die gemaakt moeten worden.

Limieten zijn er omdat we oneindigheid niet kunnen voorstellen op digitaal niveau. Misschien dat dat later wel veranderd met bvb A.I. ofzo misschien kan men dan wel manier vinden om een onbeperkt aantal gradaties tussen de 0 en de 1 te vinden, iets wat nu natuurlijk nog onmogelijk is, maar als het mogelijk is stelt dat natuurlijk wel systemen in staat om te denken in grotere termen.

En limieten worden idd wel meestal zodanig gekozen dat men er geen last van heeft maar toch komen ze soms naar boven, zie ariane, zie patriot missle maar zie ook bvb het onvoorspelbaar gedrag van een simpele datum (2k remember).

Het probleem is dat de keuzes die ze toen maakten op om een filesystem te ontwerpen nu achterhaalt zijn. In het geval van FAT waren de keuzes die ze op dat moment namen zelfs al achterhaalt. Op wikipedia is wat historie te vinden van diverse fs'en.

De keuzes waren achterhaalt maar de grote vraag is dan natuurlijk waarom andere systemen op het zelfde moment wel in staat zijn om meer geheugen te alloceren, of meer specifiek in het bestandssysteemgeval geen berperkingen te hebben op bestandsnaam (uitgezonderd de NULL dan) of qua aantal files e.d. zonder een verlies aan efficiëntie... En dat is wat alles zo interessant maakt natuurlijk.
En dat is wat ik wil weten...

[ Voor 40% gewijzigd door Verwijderd op 15-03-2004 13:48 ]

[curry684]

Verwijderd schreef op 15 maart 2004 @ 13:36:
[...]
En mijn research was misschien idd niet zo goed, ben er nog volop mee bezig hé

Dan moet je dus niet impliceren dat Ext3 tig keer beter zou zijn dan NTFS, want ik heb een subtiel vermoeden dat de superioriteit van NTFS hoogstens door XFS of Reiser naar de kroon gestoken kan worden. Ext3 is enkel een wrappertje om Ext2, wat in de praktijk ook outdated is, en NTFS is _echt_ goed, en het is dan ook niet voor niets dat Microsoft de lowlevel details zo geheim mogelijk houdt.

[Verwijderd]

curry684 schreef op 15 maart 2004 @ 13:44:
Dan moet je dus niet impliceren dat Ext3 tig keer beter zou zijn dan NTFS, want ik heb een subtiel vermoeden dat de superioriteit van NTFS hoogstens door XFS of Reiser naar de kroon gestoken kan worden. Ext3 is enkel een wrappertje om Ext2, wat in de praktijk ook outdated is, en NTFS is _echt_ goed, en het is dan ook niet voor niets dat Microsoft de lowlevel details zo geheim mogelijk houdt.

Dit zou ik niet mogen doen idd, mijn oprechte excuses daarvoor. Al ben ik meer te vinden voor één standaard waaraan men dan samen ontwikkeld. Al zal dat moeilijk zijn met "bedrijven" die twee compleet verschillende visies hebben.

nog een late reactie op:

Ik zie trouwens dat je Win2k gebruikt... wtf doe je dan in godesnaam met een FAT32 schijf? NTFS is sneller, veiliger en bevat native security. FAT32 is een hobby-FS voor thuisgebruikers met een 486 en Windows 95 voor de spelletjes....

Juist vanwege de compatibiliteit met linux hé en als student heb ik de faciliteiten die NTFS bezit niet nodig, dan kan ik meer de compatibiliteit (lees de schrijf-mogelijkheid) waarderen. Uiteraard moest dit een win2k-only systeem zijn zou ik NTFS gebruiken.
Enfin jah nu moet ik toch wel ergens een NTFS-partitie zien te krijgen want ik wil daarop ook een aantal dingen bij zien.

offtopic:
[quote]Reptile209 schreef op 15 maart 2004 @ 14:04:
[...]

[offtopic]pikachuf, klik eens op die tweede link in je sig en update 'm dan eens :D[/offtopic][/quote]
Bedankt, dat had ik nog niet opgemerkt, ik heb het veranderd.

[ Voor 43% gewijzigd door Verwijderd op 15-03-2004 14:10 ]

[Reptile209]

Verwijderd schreef op 15 maart 2004 @ 13:56:

offtopic:
pikachuf, klik eens op die tweede link in je sig en update 'm dan eens

[riezebosch]

curry684 schreef op 15 maart 2004 @ 13:30:
Sowieso kun je hoogstens de overhead verplaatsen, niet uitroeien.: een filesysteem fragmenteert per definitie. Je kunt wel met slimme algoritmes trachten om voor nieuwe files 'best-fit' locaties op te zoeken ipv een willekeurig blok te pakken, en daarmee stel je fragmentatie een eind uit. Tevens kun je dit op runtime doen bij deletes bijvoorbeeld. Maar: je herverdeelt enkel de rekentijd. FATxx zijn gebouwd op snelheid en mochten dus niet die overhead doorlopend vertonen, vandaar dat ze er op zijn gericht om regelmatig gedefragged te worden. Er zat ook niet voor niets in 95/98 en ME wel een native defrag-optie en in WinNT4 niet (was zelden nodig kan ik uit ervaring melden).

Heb geleerd dat soms juist een worst-fit beter is, omdat je dan geen kleine gaten krijgt waarin niets meer past...

[curry684]

riezebosch schreef op 15 maart 2004 @ 23:27:
[...]


Heb geleerd dat soms juist een worst-fit beter is, omdat je dan geen kleine gaten krijgt waarin niets meer past...

Dan nog wil je in principe of de perfect-fit, of een worst-fit

En om de tijd even wat stuff compressen tot contiguous blocks van data zodat je weer grote ruimtes lege tjap hebt om te vullen.

[EXX]

Verwijderd schreef op 15 maart 2004 @ 12:49:
[...]

. 't wordt tijd dat ze eens werk maken van FAT64

Een korte uitleg waarom een filesystem als FAT64 geen enkele zin heeft.

We beginnen even met FAT16. Daar heb je 2 bytes per cluster in de File Allocation Table (FAT). In totaal heb je dus 65536 clusters. Bij een maximum van 32 KB per cluster zit je op 2 GB max. grootte voor een FAT16 partitie, en de FAT kan maximaal 128 KB groot worden (aantal clusters * aantal bytes per FAT entry).

Nu gaan we naar FAT32. Daar heb je 4 bytes per cluster in de FAT. Neem een drive van bv. 128 GB (das tegenwoordig niet meer zo groot). Als je weer uitgaat van 32 KB clusters, dan wordt je op die drive 4194304 clusters. Dat geeft al een FAT van 16 MB. Ga je kleinere clusters nemen om je slack te reduceren dat wordt het nog erger. Bij 4 KB per cluster (zoals bij NTFS) wordt je FAT 128 MB groot. Dat is onhandelbaar, de FAT moet compleet in het geheugen staan om bewerkt te kunnen worden.

Bij een FAT64 systeem wordt het nog erger: daar zou je 8 bytes per cluster in de FAT hebben. Bij dezelfde drive van 128 GB wordt je FAT al 2 keer zo groot tov FAT32. Bij 4KB per cluster kom je dan uit op 256 MB. Hoe groter de drive wordt, hoe groter de FAT. Bij een drive van 256 GB zit je al op een FAT van een halve gigabyte. De enige optie is dan om weer grotere clusters te gaan gebruiken. Maar zelfs bij 32 KB clusters is bij een 256 GB drive de FAT nog steeds 64 MB.

[igmar]

curry684 schreef op 15 maart 2004 @ 13:30:
pikachuf: als je jezelf goed wil informeren, doe dan ook je research voordat je loze opmerkingen gaat roepen. Zowel Ext2 als Ext3 dienen net zoals NTFS, FAT16 en FAT32 gedefragmenteerd te worden, leert 1 minuut research me.

2 minuten zoeken leert mij dat het voor ext2 / ext3 niet nodig is :

http://www.tldp.org/HOWTO/Partition/formating.html. Op ext2 speelt fragmentatie en performance issues alleen een rol indien het FS extreem vol zit (98% ofzo).

Voor NTFS zal ongetwijfeld ook een soortgelijke regel gelden, aangezien ik nog nooit een NTFS FS gedefragmenteerd heb.

[curry684]

igmar schreef op 16 maart 2004 @ 15:19:
[...]
2 minuten zoeken leert mij dat het voor ext2 / ext3 niet nodig is :

http://www.tldp.org/HOWTO/Partition/formating.html. Op ext2 speelt fragmentatie en performance issues alleen een rol indien het FS extreem vol zit (98% ofzo).

Voor NTFS zal ongetwijfeld ook een soortgelijke regel gelden, aangezien ik nog nooit een NTFS FS gedefragmenteerd heb.

Nodig en nuttig zijn 2 verschillende dingen NTFS fragmenteert heel weinig, maar wint wel aan snelheid door te regelmatig defraggen. Nodig is het niet, nuttig wel dus, en voor ext2/3 zal hetzelfde gelden.

[Verwijderd]

Mwah fragmentatie op een ext2/ext3 FS is dusdanig weinig, dat het defragmenteren echt geen merkbaar verschil op zal gaan leveren hoor

Verder opmerkelijke uitspraken over de verschillende FS's in deze topic

[ Voor 23% gewijzigd door Verwijderd op 16-03-2004 16:09 ]

[EfBe]

igmar schreef op 16 maart 2004 @ 15:19:
2 minuten zoeken leert mij dat het voor ext2 / ext3 niet nodig is :

http://www.tldp.org/HOWTO/Partition/formating.html. Op ext2 speelt fragmentatie en performance issues alleen een rol indien het FS extreem vol zit (98% ofzo).

Voor NTFS zal ongetwijfeld ook een soortgelijke regel gelden, aangezien ik nog nooit een NTFS FS gedefragmenteerd heb.

Toch is het onzin dat ext* niet fragmenteert.

Maak 1000 files aan van clustersize*1.5 grootte. Haal alle oneven nummers weg. Je hebt ook met een inode systeem dan een mooie lappendeken. Als je dat maar veelvuldig herhaalt heb je een leuke gefragmenteerde disk die half leeg is. Je gaat dan bv een grote file op je hdd zetten, en die is dan echt gefragmenteerd.

Het punt is: fragmentaties van files is inherent aan het gebruik van fixed clusters op een hdd. Hoe je die indexeert in de index erbovenop maakt geen fluit uit: je loopt hoe dan ook tegen het punt aan dat er voor een grote file van zeg 100MB geen aaneengesloten clusterblokken meer zijn. Je file fragmenteert dan op disk.

Door die fragmentatie moet de head steppen. Een steppende head kost tijd.

M.a.w.: alle filesystems fragmenteren en zijn daardoor onderhevig aan performance verlies daardoor. Het hangt van de slimheid van het FS af of hij kleine en grote files bij elkaar zet of niet. Echter dit gaat na verloop van tijd de mist in hoe dan ook ivm gaten in de bestanden fysiek op schijf.

edit: dat artikel waar je naar link vertelt totaal niet waarom Ext* niet fragmenteert. Zoals ik al zei: veel kleine files op je hdd wegschrijven en daar dan random uit deleten is funest voor je gedefragmenteerde sectie met data. Claims als het fragmenteert niet hoor ik al OS/2's filesystem en er zijn altijd voorbeelden te bedenken waar het de mist in gaat (en nee, niet met volle hdd's ).

NTFS doet overigens ook aan slimme clustering van files op disk. Waar het fout gaat in NTFS vaak is de fragmentatie van de file allocation tablesection (en die is lastig te defraggen )

[ Voor 17% gewijzigd door EfBe op 16-03-2004 17:50 ]

[curry684]

Verwijderd schreef op 16 maart 2004 @ 16:08:
Mwah fragmentatie op een ext2/ext3 FS is dusdanig weinig, dat het defragmenteren echt geen merkbaar verschil op zal gaan leveren hoor

Zoals EfbE en ikzelf maandag al zei fragmenteert ieder FS uiteindelijk, tenzij je realtime 'unfragt'. ext2 zal dus ook bij lang intensief gebruik gedefragged moeten worden.

Verder opmerkelijke uitspraken over de verschillende FS's in deze topic

Vertel

[cavey]

Hmm

wat ik me van NTFS en EXT2 kan herinneren is dat NTFS wel degelijk fragmenteert en dat je dit ook merkt aan de systeem performance.... en EXT2 bij voorbaat al een fragmentarisch opgezet filesysteem is.

NTFS wordt trager na verloop van tijd, omdat het nog steeds het begin van de schijf vol zet.

ext2 door z'n karakter van linked inodes is sowieso al meer verspreid over de hele schijf. In beginsel zal een NTFS schijf dan ook sneller zijn dan een ext2 schijf van dezelfde grootte en partitie instellingen ........ echter, als de schijf vol begint te lopen, zit de ext2 nog op redelijk constante snelheid over de gehele schijf genomen, door het linked-inode en dus vrij fragmentarische opzet...... dan een NTFS schijf...

Die nog steeds beetje op de FAT manier de schijf vol gooit.

Magoe... echt helemaal klopt m'n verhaal niet, maar ext2 is constant traag (of snel ) en NTFS begint snel en eindigt traag........

Was toch ooit eens een slashdot artikel over? Over iemand die een zooi tests had gedaan met de verschillende FS'n die beschikbaar zijn in de computer wereld ... met wat opmerkelijke conclusies?

Hmm, blijkbaar had ik het mis. dichtsbijzijnde link waar ik op kon komen ging over verschillende JFS'n in de 2.6 kernel van linux...

http://kerneltrap.org/node/view/715

Oh well. Ik zal m'n Operating Systems boekje er later eens op na slaan hoe het klok-klepel verhaal ook alweer zat met ext2 fs en dergelijke

[ Voor 4% gewijzigd door cavey op 17-03-2004 11:11 ]

[EfBe]

NTFS wordt trager na verloop van tijd, omdat het nog steeds het begin van de schijf vol zet.

Dat is met opzet zo omdat bij inactiviteit een hdd kop naar het begin van de harddisk wordt gedirigeerd. Vandaar dat de MFT ook daar staat (bij het moven naar de file komt de kop toch over die table heen, dus geen extra stepping).

[curry684]

For the record:

quote: http://en.wikipedia.org/wiki/NTFS

Internally, NTFS uses binary trees in order to store the file system data; although complex to implement, this allows fast access times and decreases fragmentation.