Hoofdcategorieën

Windows Server 2003 SP1 heeft datacorruptieprobleem

Door Harm Hilvers, vrijdag 4 november 2005 23:28
Bron: Microsoft, submitter: bierbuik, views: 16.968

Windows Server 2003 LogoMicrosoft draait regelmatig stresstests om te kijken tot welke prestaties het bestandssysteem NTFS in staat is en welke problemen eventueel optreden. Tijdens het uitvoeren van deze tests op Windows Server 2003 met service pack 1 geïnstalleerd is gebleken dat in enkele uitzonderlijke gevallen datacorruptieproblemen kunnen ontstaan. Problemen kunnen mogelijk, niet in alle gevallen ontstaat namelijk datacorruptie, optreden als voldaan wordt aan alle vier de volgende voorwaarden: (1) de server heeft meerdere CPU's; (2) er worden 1000 simultane delete-, create- en extendbewerking uitgevoerd op het NTFS-volume; (3) het NTFS-volume is bijna vol; en (4) de server bevat kleine NTFS-volumes. Naar mate de NTFS-volumes groter worden en de I/O-belasting van de server afneemt, daalt de kans dat problemen ontstaan. Aan een hotfix voor dit probleem wordt gewerkt en deze wordt al getest, maar Microsoft wilde toch melding van dit probleem om te voorkomen dat er mogelijk problemen ontstaan bij bedrijven die dit service pack willen uitrollen. Het probleem zou volgens het Redmondse softwarebedrijf niet bij andere Windows-versies voor kunnen komen.

Volgende 00:10
Vorige 21:52

Reacties

«  1  2  »

Da bijzonder tof ;(

Gezien het feit dat het redelijk laat ontdekt/openbaar gemaakt wordt (SP1 is toch al even uit), zal de kans dat het effectief fout gaat wel redelijk klein zijn. Dit wordt nog eens bevestigd door de 4 voorwaarden? Maar toch, je wil niet de systeemeheerder zijn als er door zo'n patch ineens een paar gigabyte aan data corrupt is geraakt.
Wie weet merk je het niet eens voor je backup-retentie verstreken is :o


Je kunt nu eenmaal niet alles 100% testen. Ik vind het eigenlijk wel netjes dat ze een fout die bijna nooit optreedt toch melden in plaats van gewoon niets te zeggen en op het beste te hopen.

Natuurlijk is dit ook in hun eigen belang, want als ze niets zeggen en het komt uit, dan schaadt dat het vertrouwen en dat is waarschijnlijk veel erger op de langere termijn.

Denk na.. Het gaat om zeer uitzonderlijke situaties. Je kan bijna zeggen dat dit in de praktijk niet voorkomt. Als het al voorkomt dan is het nog niet eens echt een probleem als je de zaakjes op orde heb.

Niks aan het handje dus.

Wat een VOLSLAGEN onzinnige uitspraak.
Microsoft komt zelf met het probleem en werkt aan een oplossing, de kans dat iemand dit probleem kan hebben en het merkt is klein.
Ik vind dit alleen maar een goede stap van microsoft door zo goed te testen en er bekenheid aan te geven.

Ik zie het al voor me:
Microsoft heeft een probleem ontdekt waar vrijwel niemand last van heeft en werkt aan een hotfix, laten we gelijk migreren naar Linux
:?

Waarom moet er altijd meteen Linux bijgehaald worden als er weer wat "fout" is in een Microsoft product.
(2) er worden 1000 simultane delete-, create- en extendbewerking uitgevoerd op het NTFS-volume
Nummer 2: lijkt me wel zo onwaarschijnlijk dat dit ooit zal voorkomen. dan moeten 1000 mensen precie sop het zelfde moment 1 van deze uitvoeringen doen. Dit kan gewoon niet.

En of er in Linux nooit een foutje word gevonden. Dat word niet meteen van de daken geschreeuwd omdat dat heel normaal is. :?

En of er in Linux nooit een foutje word gevonden. Dat word niet meteen van de daken geschreeuwd omdat dat heel normaal is.
Tja, laten we maar niet beginnen over de datacorruptie in de 2.4 reeks van de Linux kernel (2.4.11-dontuse enzo). ;)
Ik vind het een nette afhandeling van MS :)

1000 mensen precies hetzelfde doen? :?

Dat slaat nergens op, een druk belaste database of indexing server heeft makkelijk zoveel bewerkingen gelijktijdig.
Niet alleen mensen benaderen files hoor, er bestaat ook nog zoiets als applicaties.
Rare beredeneringen houd jij er op na ;)

Evengoed zal het concrete risico klein zijn, maar de impact is wel knap groot te noemen.

Lees eerst de KB eens:
If a scenario is very different, the chance that this corruption will occur is very low. For example, the problem is very unlikely to occur if the following conditions are true:
A server has very large volumes.
Few delete, create, and extend operations occur.
Database operations typically involve I/O with previously allocated files.

Dat wordt een patch schrijven voor een zeer uitzonderlijke situatie. Ik denk dat je dit probleem in "het wild" nooit tegen zult komen.

Dit geeft wel wat meer vertrouwen in het testen van MS!

Dat vraag ik me af. Ligt er aan of we het PR statement voor ons hebben of het advies van een developer. Eerlijk gezegd: ik weet hetniet, maar het probleem had er niet in mogen zitten.

P.S.:
Denk je echt dat MS dit probleem had gepubliceerd als het theoretisch probleem zou zijn? Ge a life! Trek je eigen conclusie!

Nee, natuurlijk niet, dan zouden ze gewoon in het geheim deze patch uitbrengen, maar wel zorgen dat het ook overal geinstalleerd word.
Maar het geeft wel weer iets meer vertrouwen in het testen van MS.
In het echt zullen 1000 simultane bewerkingen op 1 volume natuurlijk erg onwaarschijnlijk zijn opzich. Dat er meerdere cpu's in een server zitten is niet onwaarschijnlijk, maar het moet OOK NOG bijna helemaal vol zitten. Ook iets wat erg onwaarschijnlijk is als het nog zo druk bezig is met simultane bewerkingen. Het lijkt mij dat op een drukke server het volume uitgebreid zal worden voor het zo extreem vol zit (ff uitgaande van een raid volume, want 1000 operaties op 1 schijf is ook vrijwel ongehoord)

knap hoor zo positief reageren op dit bericht.
ik draai sp1 al een jaar uit aan klanten, en vind dit toch een behoorlijk cruciale/jammerlijk bug.

vind het tegenvallen juist omdat ik niet zo veel hele serieuze bugs meer tegenkom, en deze zou dramatisch (kunnen) zijn in een grote omgeving.

Vind je? De kans dat dit in het wild gebeurt is nihil. Ten eerste moet het system continue voor meerdere uren zeer zwaar belast worden en ten tweede moeten de volumes kleiner dan 24GB zijn. Disken van 18GB zijn al jaren niet meer leverbaar bij bv Compaq/HP en Sun. En de hoeveelheid IO die er op het systeem moet zijn is dermate hoog dat je dat in de praktijk niet of nauwelijks continue tegenkomt.

Als je deze situatie wel tegenkomt, dan draai je waarschijnlijk een systeem dat zowat kreunend tot stilstand komt en smeekt om een upgrade en waarschijnlijk zo oud is dat je er waarschijnlijk ook geen W2K3 op hebt draaien.

Al eens bedacht dat 1 disk meerdere volumes kan bevatten?
Voor sommige toepassingen wil je juist geen grote volumes, en dat heeft niks met de ouderdom van een systeem te maken.

En van 1000 simultane bewerkingen schrik ik nou ook niet echt, ik zie dagelijks genoeg systemen die het wel halen.

De kans dat je idd 1000 simultane acties ziet op een server is echt heel erg klein.

OK, ik heb ook een aantal systemen die makkelijk boven de 1000 file-operations per seconde doet. Maar dat is niet simultaan. Daarvoor heb je heel wat meer operations per seconde voor nodig en dus een hele volle disk-queue.

Dit zul je vrijwel nooit in een live omgeving zien aangezien dit betekent dat de server een hele slechte performance heeft bekeken vanuit menselijke acties.
Voor een data 'verwerkings' systeem is dit minder een probleem tijdens piek-tijd; echter dit soort acties zijn met slechts een aantal uitzonderingen transactioneel, zodat de kans op uiteindelijke data corruptie nog kleiner wordt.

In een datawarehouse-omgeving kan dit probleem zich voordoen tijdens ETL-processen, i.e. wordt al redelijk vlot voldaan aan de voorwaarden, helemaal als je om performance redenen je TEMPDB op een apart volume onderbrengt. In dat kader wordt interessant wat bedoeld wordt met 'extend operations'. Als dit de autogrow functionaliteit is, kan een dolgedraaide query die TEMPDB benut al voldoende zijn...

ik draai sp1 al een jaar uit aan klanten, en vind dit toch een behoorlijk cruciale/jammerlijk bug.
Ik dacht dat ie pas sinds mei uit was ofzo? Half jaartje dus.
Lekkere systeembeheerder ben jij dan, als jij je klanten op beta's laat draaien :Z

Ik zie er ook niets positiefs in. Moet je toch wel een beetje de weg kwijt zijn hoor.

Serieuze bugs genoeg. OOM situaties zijn nog steeds een drama, alsmede van die vage hangende applicaties zo her en der. (met name de snap-ins). Ook hebben we het niet over de sh*t die optreedt als een service niet goed opstart (denk even terug aan een verlopen certificate van een APC product -- je hele systeem loopt op een hoop). En dan nog de ellende die je op je hals haalt als je SP1 later installeert. Niemand die weet of je systeem goed blijft werken, of die nog wil booten, noem maar op.

En een DC/Exchange/Fileserver die een kwartier er over doet om te restarten is ook niet echt normaal te noemen. Of wat dacht je van inconsistencies in de AD ? Je zoekt je de blubber als een imap account niet wil werken omdat er op de een of ander manier twee Aliassen gelijk zijn. En zo kan ik uren doorgaan.

Heel windows 2003 valt tegen, qua prijs, performance, reliability, monitoring. manageability.

Nou ben ik ook geen geweldige MS fan, maar ze kunnen het gewoon nooit goed doen.Wat had jij dan gewild?Moet MS dan maar geen tests meer uitvoeren, of de boel doodzwijgen?Ik vind het netjes dat ze deze bug überhaupt gevonden hebben en nog beter dat ze met een waarschuwing komen.Dat er nog -tig andere bugs zijn doet daar niks aan af ;)

En een DC/Exchange/Fileserver die een kwartier er over doet om te restarten is ook niet echt normaal te noemen.
Ervaren Exchange-beheerders weten gelukkig dat je ook eerst handmatig de Exchange SA moet stoppen voordat je een server shutdownt of reboot. Scheelt een kwartier of meer.

Alleen als dat ook een DC is.
Best practice is dan ook om Exchange niet op een DC te zetten.
Kan wel, alleen krijg je dan je voornoemde "probleempje".

Die "Best Practice" gaat meestal niet op in een SBS oplossing bij kleine ondernemingen met 15 medewerkers

Maar idd, er zijn zat dingen inhoudelijk te vinden die vertellen dat je eerst Exchange services moet stoppen voor je een dergelijke server reboot.- Dit is meen ik me te herinneren overigens een onhebbelijkheidje wat naar mijn weten iig ook in de Windows 2000/ Exchange 2000 combi zat.

Windows 2003 valt me 100% mee. een beste performance, beduidend stabilere omgeving - issues daargelaten die uitstekend waren op te lossen - monitoren gaat me best af, en remote management is ook aanzienlijk verbeterd t.o.v. 2000.

Er zitten wat mindere puntjes aan SP1, waardoor ik nog niet live er mee werk. Zo zit er een geheugen management issue in wanneer er gebruik wordt gemaakt van Terminal Services. Da's voor ons een showstopper geweest, en dan hebben we nog het probleem dat ik nogal lang moest wachten op de nieuwe Dell Open Manage omdat de 4.3 en voorgaande versies niet geschikt waren voor SP1 - maar dat mag je MS niet verwijtn.

Bij echt goed testen was dit probleem gevonden en verholpen voordat SP1 uitgebracht was.

Bij mij rijst nu de vraag hoeveel andere problemen er niet zijn gevonden voordat SP1 GM ging.

Edit: Oeps, was bedoeld als reactie op jantje.vlaam

Geld dit ook voor 1 CPU met Hyper Threading...

In het artikel (http://support.microsoft....aspx?scid=kb;en-us;909360) staat daar niets over. De enige die dat met zekerheid kan zeggen lijkt me MS zélf. Mensen die beweren dat dit zo zou zijn (dus dat het optreedt met HT CPU's) kunnen er langs zitten, want je zult nooit 100% kunnen achterhalen of het dezelfde bug is of een compleet losstaande.

MS is zelf ook nogal vaag in hun artikel (zeker voor hun doen), en ik vermoed dan ook dat ze het probleem dus wel hebben kunnen reproduceren, maar nog niet zeker weten waar het zit. De tijd zal het leren, maar ik verwacht op korte termijn wel een patch (uiteraard ook mede door de "ernst" van de zaak).

Overigens zegt dit, IMHO, weinig over het testwerk van MS. Hoewel ik redelijk MS aanhanger ben, en er van overtuigd ben dat hun testafdeling prima werk levert doorgaans, lijkt me dit probleem dusdanig specifiek en "zeldzaam" dat ze het waarschijnlijk gewoon via klachten van meerdere bronnen hebben gekregen en pas na de x-te klacht begon er een lampje te branden en zijn ze omgevingscondities langs elkaar gaan leggen... _lijkt me_

Dit lijkt mij juist iets wat naar voren komt als je gestuctureerd test. De meeste mensen zullen namelijk niet in eerste instantie aan het OS denken als er schijnbaar op willekeurige momenten data corruptie optreed.

Echter als je een stresstest doet en van te voren weet wat de uitkomsten moeten zijn en die uitkomsten kloppen niet ga je het probleem als bedrijf analyseren. Een klacht als "mijn data is corrupt" van een klant die het probleem ook niet kan reproduceren wordt vaak veel minder serieus genomen.

De meeste mensen zullen namelijk niet in eerste instantie aan het OS denken als er schijnbaar op willekeurige momenten data corruptie optreed.
Het ligt dan ook niet direct aan het OS, eerder aan het bestandsysteem (NTFS), of zo begrijp ik toch uit het artikel, en als er datacorruptie is zou dat idd wel een mogelijke kandidaat zijn.

Het ligt wel aan het OS, als het aan het NTFS had gelegen hadden andere windows versies er ook last van gehad.

MS is zelf ook nogal vaag in hun artikel (zeker voor hun doen),
Sorry? zeker voor hun doen? MS is briljant in het schrijven van vage artikelen of artikelen die maar de helft van de feiten bevatten. Zoek in de support database maar eens naar een willekeurige foutmelding voor Windows XP. Zul je zien dat die foutmelding wél voorkomt in 2000, maar niet in XP. Of wél in 2000 en XP, maar niet in 2003. Terwijl je server op dat moment wel die foutmelding aan het loggen is in de eventlogs...

Goede vraag ... Ik heb overigens nog voor SP1 eens een data-corruptie probleem gehad onder Win2k3 ... Al mijn bestanden waren "wezen" (Orphaned child) geworden ...
Dat nadat hevige netwerkbelasting ... (bestanden van 700 MB werden tegelijkertijd afgehaald via het netwerk en tegelijkertijd werden er weggeschreven ...)

Misschien had je dan toch een bepaalde update van MS binnen, die ook zorgt voor het probleem in SP1?
Maar de gestelde voorwaarden zijn wel erg extreem, ik denk dus dat het niet een groot probleem zal zijn. Wel netjes van MS om het te melden.

refriednoodle:

ja van exchange weet ik dat wel, omdat AD eerder afgeknald wordt dan de exchange componenten. Het geeft alvast aan dat een simpele start/stop volgorde bij MS al ernstig te hoog gegrepen is.

Ik geef alleen maar aan dat MS basale zaken al niet op orde heeft. Vreet alle memory maar eens weg. een OOm killer -- nooit van gehoord. Garbage collectors -- nooit van gehoord. Normale defaults voor w3proxy -- nooit van gehoord. Duw maar eens 8 GB in een systeem en laat dan w3proxy met default values starten. Werkt dus niet.

Dat soort zaken werkt irritaties in de hand. Jouw opmerking "ervaren exchange admins weten dat...' geeft precies het probleem aan. MS admins schijnen het allemaal normaal te vinden dat je voor van alles en nog wat kunstgrepen moet uithalen. In plaats van dat dat soort bugs opgelost worden....

Herinner je je nog het APC debacle ? Ook zo'n probleem met het starten van services.

Over dat APC debacle:

Waarom hebben andere fabrikanten van UPS apparatuur dan geen problemen opgeleverd? Die maken immers gebruik van dezelfde door APC notabene ontwikkelde techniek die MS weer als API aanbiedt.

en even voor de duidelijkheid, het punt van een UPS is dat bepaalde services daarop dependant worden gezet om je servert netjes te kunnen afsluiten.

Dat APC zo stronteigenwijs is om een certificaat te laten verlopen en diens klanten daarvan niet voor te waarschuwen kan je MS niet verwijten.

Exchange:
Ik zei het eerder ook al; eigenlijk wil je Exchange ook niet op een DC hebben draaien. Om een heel simpele reden, namelijk performance. Je draait twee database pakketten op dezelfde server.
Das LVT (leuk voor thuis) of voor kleine omgevingen <50 man maar niet aan te raden.

Dit zul je niet geloven, ben gewoon thuis aan het overwerken omdat we vaak datacorruptie problemen hebben op een server van ons met daarop uiteraard Windows 2003 SP1... |:( |:(
Laatst zelfs de hard disks vervangen.
Nu maar hopen dat er SNEL een patch komt.
Gelukkig heb ik nu een idee waar het aan kan liggen...
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 00:10
Vorige 21:52
VNU Media logo Powered by True

© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden

Uitgever van: