[C++ / C#] HDD full warning event based maken

[Verwijderd]

In een windows-only (momenteel XP) applicatie welke veel werkt met grote files (max 150MB per stuk) heb ik een waarschuwingssysteem gemaakt welke controleert of de verschillende partities voldoende vrije ruimte hebben.

Een eerste implementatie kijkt (mbv GetDiskFreeSpaceEx) elke minuut hoeveel vrije ruimte er nog is en als deze onder de 3% komt waarschuwt ie. 3% komt overeen met 400MB en dat kan een moderne schijf in enkele seconden vol schrijven.

Wegens performance zie ik het niet zitten om het systeem elke paar seconde deze check te laten doen.

Weet iemand of je Windows zo ver kan krijgen dat je dit event-based kan maken?
(C++, C# .net of WMI maakt niet uit)

Ik heb zitten zoeken via google en op msdn, maar kan hierover geen events vinden.

[Niemand_Anders]

waarom wil je niet elke seconde een check doen dan? De tijd van de checks zou je kunnen laten afhangen van het percentage dat nog vrij was bij de laatste controle. Bij meer dan 10% vrij, elke minuut een check. Tussen 5% en 10% elke 20 seconden een check, tussen 3% en 5% elke 5 seconden een check en < 3% elke seconden een check.

Voor computers duurt een seconde een eeuwigheid en daarbij is het ook net zo dat zo'n check ontzettend zwaar is. Vergelijk jouw controle eens met hetgeen wat games per seconde aan frames moet genereren.

En stel dat deze controle ervoor zou zorgen dat de CPU load naar 3% zou gaan. Is dat op dat moment dan zo erg? Ik denk van niet. De persoon van die computer kan op dat moment gewoon elke moment serieuze problemen krijgen..

[FireDrunk]

Ik kan me niet voorstellen dat zo'n simpele check zwaar is voor je pc... Elke 3 seconden een check van een paar milliseconden boeit echt niet zoveel...

Ontopic:
Nee, ik heb hier ook wel eens naar gezocht, maar er is geen eventbased check.
Enige eventbased is FileSystemWatcher, maar die houdt geen vrije ruimte bij.

[ Voor 36% gewijzigd door FireDrunk op 04-08-2010 10:50 ]

[Verwijderd]

Het is geen desktop systeem, maar eentje waar automatisch een zware applicatie op draait en deze check is onderdeel van die applicatie. Performance is een kritisch item voor deze applicatie.
Alles wat hierin bespaard / gewonnen kan worden is positief

Maar dat is nu niet de discussie die ik graag wil voeren.

[ Voor 10% gewijzigd door Verwijderd op 04-08-2010 11:06 ]

[Reptile209]

Zijn er andere activiteiten op het systeem die de schijfruimte kunnen beïnvloeden? Zo niet, dan hoef je natuurlijk alleen voor iedere nieuwe file te checken of je nog genoeg ruimte hebt. Zo wel, dan moet je toch een keuze maken (of aan je user voorleggen) om iets performance in te leveren, of op te houden met andere activiteiten uit te voeren.
Is het een optie om 'dummy files' aan te maken, die alleen de grootte hebben (gereserveerd), maar die bloedsnel gemaakt worden? Dan kan je bij het begin van iedere file je ruimte claimen (indien voorhanden) en hoef je dus alleen dan een check te doen.

[Woy]

Verwijderd schreef op woensdag 04 augustus 2010 @ 10:58:
Het is geen desktop systeem, maar eentje waar automatisch een zware applicatie op draait en deze check is onderdeel van die applicatie. Performance is een kritisch item voor deze applicatie.
Alles wat hierin bespaard / gewonnen kan worden is positief

Als dat zo is, kun je vast ook wel vertellen wat de impact van het callen van GetDiskFreeSpaceEx is, aangezien je alles al uitgebreid geprofiled hebt.

Ik kan me namelijk niet voorstellen dat het een zware call is, waar jij wat van zult merken op je performance.

[kluyze]

Ik weet niet of je hier wel zo veel winst uit kan halen, een event moet ook ergens getriggerd worden, en wanneer zou je gaan controleren of een event getriggerd moet worden? Alle keren er een I/O operatie is? Ik gok dat dat meer is als 1 keer per seconde.

Hoe kom je aan die waarden, is 3% niet wat weinig? Wie/wat moet daar op reageren. Je zegt zelf dat dat op een paar seconden vol kan zitten, als daar een persoon op moet reageren is die nooit op tijd.
Misschien is het dan handiger om die waarde wat hoger te zetten en de tijd wat langer. Indien een andere applicatie daar op reageert door ruimte vrij te maken dan is dat natuurlijk een ander verhaal.

Wat misschien ook mogelijk is om de frequentie af te laten hangen van de hoeveelheid vrije schijfruimte.
Dus bv indien de schijf voor 50% vrij is maar om het uur laten controleren, gaat die dan richting de 60%, de frequentie verhogen naar 1 keer per half uur, 70% geeft een keer per 15min. Je moet dan zelf even beslissen hoe je dat implementeert zodat de hdd van 50% niet vol geschreven kan worden in de periode die je daarvoor instelt.

[Verwijderd]

en als je toch de performance aan het meten bent, kijk dan meteen naar performancecounters of wmi. deze geven ook disk space terug, de vraag is natuurlijk of die niet gewoon GetDiskFreeSpaceEx gebruiken onder water.

[Verwijderd]

De timing laten afhangen van de vrije ruimte in combinatie met een FilesystemWatcher staat mij wel aan.

Het is natuurlijk erg prettig dat er word meegedacht over de performance, maar het gaat niet over de performance van GetDiskFreeSpaceEx, maar van de gevolgen.

Let me explain:
Elke keer dat de vrije ruimte word gecontroleerd dient dit persistent te worden weggeschreven (File IO). Ook dienen andere onderdelen via een IPC mechanisme (process scheduling) op de hoogte te worden gebracht. Sommige van deze onderdelen moeten ook weer gaan lezen en schrijven en op hun beurt misschien weer communiceren met anderen. Dit alles gaat gepaard met de nodige logging, locks, mutexen, sockets enz. enz.
Zo escaleren de kosten van een ogenschijnlijk simpele check.

@kluyze: Het zijn inderdaad applicatie onderdelen welke moeten beslissen om minder schijf ruimte te claimen of om schijf ruimte vrij te geven

[RobIII]

Als je de zaak eens omdraait en vooraf al probeert te claimen wat je nodig gaat hebben (of nodig denkt te gaan hebben); dan weet je op voorhand al dat dat block 'yours' is en dat het past. Daarna ga je het vullen en loop je nooit meer tegen een volle schijf aan. Op het moment dat je een nieuw block gaat claimen (vooraf) dat niet gaat passen kun je alsnog een eigen event raisen en daar iets mee doen.

[LauPro]

Waarom geef je niet in je applicatie op wat het maximum is dat gebruikt mag worden aan opslagruimte? Desnoods pak je standaard de schijfcapaciteit - 10GB. En dan moet je vervolgens zelf bijhouden hoeveel files (en hun grootte) je hebt gealloceerd.

[Phyxion]

@kluyze: Dat is wel een hele slechte oplossing, alhoewel ik niet weet hoe groot de files zijn die weggeschreven worden. Als je zeg maar 100GB vrij hebt van de 250GB zou je niet vaak moeten controleren, maar stel er komt twee keer een bestand van 50GB langs dan zit de drive al vol.

@LauPro: Dat lijkt me inderdaad de beste oplossing.

[ Voor 8% gewijzigd door Phyxion op 04-08-2010 11:59 ]

[kluyze]

Daarom dat ik ook aangeef dat hij zelf gaat moeten kijken met welke frequentie er gecontroleerd wordt. Als hij elke seconde op 3% controleert gaat hij in jouw voorbeeld ook niets doen want dan is er nog steeds 50GB (>3%) vrij. En een bestand(en) van in het totaal 150GB heb je ook niet op 1 seconde naar je schijf geschreven.

[Verwijderd]

@Phyxion: gelukkig weten we wel hoe groot de files zijn:

Verwijderd schreef op woensdag 04 augustus 2010 @ 10:31:
grote files (max 150MB per stuk)

De oplossing van LauPro lijkt mij een 100% zeker sluitende oplossing, onafhankelijk van HDD snelheden, file formaat en andere variabelen.
Het enigste is, de overhead van elke file aanvragen flink kan oplopen.
Dat is helemaal zonde als er ruim voldoende HDD ruimte is en het systeem snel veel kleine files wilt gaan maken / vrijgeven.

Zoals verteld gaat communicatie via IPC call's en dat is echt niet gratis.

[Korben]

Elke keer dat de vrije ruimte word gecontroleerd dient dit persistent te worden weggeschreven (File IO). Ook dienen andere onderdelen via een IPC mechanisme (process scheduling) op de hoogte te worden gebracht. Sommige van deze onderdelen moeten ook weer gaan lezen en schrijven en op hun beurt misschien weer communiceren met anderen. Dit alles gaat gepaard met de nodige logging, locks, mutexen, sockets enz. enz.
Zo escaleren de kosten van een ogenschijnlijk simpele check.

Gaap.

C#:

if (freeSpace != previousSpace) {
  WasteResourcesCommunicatingThis();
}
else {
  // control flow statements are the best new feature in programming languages evar!
}

Je geeft namelijk zelf al aan dat het event-based mag, dus het is niet nodig om elke keer dat het gecontroleerd wordt dit te communiceren.

[ Voor 9% gewijzigd door Korben op 04-08-2010 12:58 ]

[MSalters]

3% komt overeen met 400MB en dat kan een moderne schijf in enkele seconden vol schrijven.

Ik zou je huiswerk eens opnieuw doen. Als je 3% in een paar seconden vol kunt schrijven, dan kun je 100% in een minuut of twee volschrijven. Er zijn nooit harddisks geweest die dat konden. Jouw voorbeeld harddisk (400 MB / 3% = 12 GB) is dusdanig oud dat die nog schrijfsnelheden van ~10 MB/sec had, en dus over 400 MB ruim 40 seconden zou doen. Een moderne harddisk die 60 MB/sec haalt (non-cached) is alweer 1 TB; 3% is dan 3000 MB en goed voor 50 seconden data.

[Woy]

MSalters schreef op donderdag 05 augustus 2010 @ 11:51:
[...]


Ik zou je huiswerk eens opnieuw doen. Als je 3% in een paar seconden vol kunt schrijven, dan kun je 100% in een minuut of twee volschrijven. Er zijn nooit harddisks geweest die dat konden. Jouw voorbeeld harddisk (400 MB / 3% = 12 GB) is dusdanig oud dat die nog schrijfsnelheden van ~10 MB/sec had, en dus over 400 MB ruim 40 seconden zou doen. Een moderne harddisk die 60 MB/sec haalt (non-cached) is alweer 1 TB; 3% is dan 3000 MB en goed voor 50 seconden data.

Maar je kunt natuurlijk ook kleinere partities op moderne HD's tegen komen, en dan klopt het wel.

[.oisyn]

En oh ja, bestonden er tegenwoordig ook niet SSD's? Weinig data en loeisnel enzo.

[ Voor 22% gewijzigd door .oisyn op 05-08-2010 12:38 ]

[LauPro]

Zo zie je maar hoe gevaarlijk het is om dit soort harde constanten in je code op te nemen. Ik zou aanhouden:
• minimaal 10GB vrijhouden.
• & minimaal 5% schijfruimte vrijhouden.

Zit je redelijk safe denk ik. Al hoewel ik geen idee heb hoe de overhead op hele grote filesystems gaan zijn. Eigenlijk is het ook van de gekke dat een applicatie zich hier druk om moet maken, zullen ze in de unixwereld vast al iets op hebben bedacht (virtual disk space size for apps etc).

[Niemand_Anders]

LauPro schreef op donderdag 05 augustus 2010 @ 12:48:
Eigenlijk is het ook van de gekke dat een applicatie zich hier druk om moet maken, zullen ze in de unixwereld vast al iets op hebben bedacht (virtual disk space size for apps etc).

Ja, maar als de ruimte op is, dan is ie toch echt op. En dan kan Unix nog zo fantastisch zijn, het zal niet meer kunnen opslaan dan de partitie toestaat.

Dit probleem komt eigenlijk zeer vaak (bewust) voor op unix, linux en BSD systemen. De meeste server systemen hebben al snel 6 tot 8 verschillende partities juist om te voorkomen dat process A, process B in de voeten kan rijden door alle schrijf ruimte op te maken.

In een ver verleden (+/- 1998) was ik vergeten op een gateway machine /var/log en /var te splitsen. Door een aanhouden ddos attack (welke door ipchains werd gelogd naar syslog) raakte de var partitie vol. 's ochtend kwamen de developers weer opdagen, maar konden niet aan de slag omdat hun PC geen IP adres meer had. De DHCP server kon in /var/lib de dhcp leases niet meer wegschrijven..

Schrijfruimte is niet oneindig en elke respecterende applicatie welke bestanden wegschrijft dient gewoon te controleren of er nog genoeg ruimte is. Of in elk geval netjes om te gaan met een eventuele melding dat er geen ruimte meer is. Daarnaast lijkt het mij dat in het geval de TS de machine ook gemonitord wordt door tools zoals BigSister welke geheugen, schrijfruimte, processor belasting, etc allemaal in de gaten houden. Dergelijke systemen hebben ook allemaal de mogelijkheid om alerts te versturen (per mail, pager, sms, im) zodra een bepaald niveau wordt behaald.

Tegenwoordig is het met virtualisatie wel gemakkelijker geworden om schrijfruimte voor virtual machines te beheren. Ik weet dat het mogelijk is om nieuwe virtual disks aan een machine te koppen. Onder linux kon ik enkele maanden terug door 'udevd' een hup te geven de nieuwe partitie direct mounten en in gebruik nemen. Ik denk echter dat Windows een herstart nodig heeft om de nieuwe partitie te controleren..

[DutchKel]

Is dit niet iets:

http://msdn.microsoft.com/en-us/library/5z57dxz2.aspx

Ik heb het vluchtig bekeken dus ik weet het niet zeker.

[RobIII]

kfaessen schreef op donderdag 05 augustus 2010 @ 18:00:
Is dit niet iets:

http://msdn.microsoft.com/en-us/library/5z57dxz2.aspx

Ik heb het vluchtig bekeken dus ik weet het niet zeker.

Gefeliciteerd! Je hebt een artikel gevonden over hoe je (eigen!) events gebruikt in een class. Als je even "vluchtig" de eerste 3 regels uit dat artikel had gelezen en de topicstart dan had je je de moeite van de post kunnen besparen

[ Voor 17% gewijzigd door RobIII op 05-08-2010 20:01 ]

[Mijzelf]

MSalters schreef op donderdag 05 augustus 2010 @ 11:51:
[...]


Ik zou je huiswerk eens opnieuw doen. Als je 3% in een paar seconden vol kunt schrijven, dan kun je 100% in een minuut of twee volschrijven. Er zijn nooit harddisks geweest die dat konden.

<mieren**kmodus>
Jawel hoor. Mijn IBM uit 1985 had een 10 MB harddisk, met een schrijfperformance van ongeveer 250kB/sec. Die schrijf je dus vol in 40 seconden. (Vooropgesteld dat je *zo snel* *zo veel* data kunt genereren.)
</>