If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
CHKDSK killed my OpenGL subsystem
Today when I booted my computer checkdisk ran automatically, "fixed" some
errors, and simply rebooted leaving me in a state of cluelessness. Fortunately I could retrieve the information via: Event Viewer-Application Source:WinLogon: Here is the chkdisk report: " Checking file system on C: The type of the file system is NTFS. One of your disks needs to be checked for consistency. You may cancel the disk check, but it is strongly recommended that you continue. Windows will now check the disk. Index entry nvoglnt.dll of index $I30 in file 0x1d points to unused file 0xc958. Deleting index entry nvoglnt.dll in index $I30 of file 29. Index entry resume.el of index $I30 in file 0xc76b points to unused file 0xc959. Deleting index entry resume.el in index $I30 of file 51051. Index entry Unit1.dfm of index $I30 in file 0xc90d points to unused file 0xc95a. Deleting index entry Unit1.dfm in index $I30 of file 51469. Index entry Unit1.pas of index $I30 in file 0xc90d points to unused file 0xc95b. Deleting index entry Unit1.pas in index $I30 of file 51469. Cleaning up minor inconsistencies on the drive. Cleaning up 48 unused index entries from index $SII of file 0x9. Cleaning up 48 unused index entries from index $SDH of file 0x9. Cleaning up 48 unused security descriptors. CHKDSK discovered free space marked as allocated in the master file table (MFT) bitmap. CHKDSK discovered free space marked as allocated in the volume bitmap. Windows has made corrections to the file system. 11550703 KB total disk space. 10344776 KB in 215692 files. 91180 KB in 22706 indexes. 0 KB in bad sectors. 321155 KB in use by the system. 65536 KB occupied by the log file. 793592 KB available on disk. 4096 bytes in each allocation unit. 2887675 total allocation units on disk. 198398 allocation units available on disk. Internal Info: 54 e1 03 00 49 a3 03 00 62 8c 05 00 00 00 00 00 T...I...b....... 60 27 00 00 00 00 00 00 f0 01 00 00 00 00 00 00 `'.............. 20 85 2e 12 00 00 00 00 20 08 2c db 01 00 00 00 ....... .,..... f0 05 5b 0e 00 00 00 00 00 00 00 00 00 00 00 00 ..[............. 00 00 00 00 00 00 00 00 40 0b c2 06 02 00 00 00 ........@....... 99 9e 36 00 00 00 00 00 8c 4a 03 00 00 00 00 00 ..6......J...... 00 20 65 77 02 00 00 00 b2 58 00 00 00 00 00 00 . ew.....X...... Windows has finished checking your disk. Please wait while your computer restarts. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. " Then later when I tried to start "Return to Castle Wolfenstein Multiplayer Demo": " Wolf 1.1 win-x86 Dec 17 2001 ----- FS_Startup ----- Current search path: F:\GAMES\Return to Castle Wolfenstein Multiplayer DEMO/main ---------------------- 0 files in pk3 files Running in restricted demo mode. ----- FS_Startup ----- Current search path: F:\GAMES\Return to Castle Wolfenstein Multiplayer DEMO\demomain\pak0.pk3 (1846 files) F:\GAMES\Return to Castle Wolfenstein Multiplayer DEMO/demomain ---------------------- 1846 files in pk3 files execing default.cfg couldn't exec language.cfg execing wolfconfig_mp.cfg usage: seta variable value execing autoexec.cfg Hunk_Clear: reset the hunk ok ....detecting CPU, found Intel Pentium III Bypassing CD checks ----- Client Initialization ----- ----- Initializing Renderer ---- ------------------------------- Loaded 714 translation strings from scripts/translation.cfg ----- Client Initialization Complete ----- ----- R_Init ----- Initializing OpenGL subsystem ....initializing QGL ....calling LoadLibrary( 'C:\WINDOWS\System32\opengl32.dll' ): succeeded ....setting mode 3: 640 480 FS ....using colorsbits of 32 ....calling CDS: ok ....registered window class ....created window@0,0 (640x480) Initializing OpenGL driver ....getting DC: succeeded ....GLW_ChoosePFD( 32, 24, 0 ) ....35 PFDs found ....GLW_ChoosePFD failed ....failed to find an appropriate PIXELFORMAT ....restoring display settings ....WARNING: could not set the given mode (3) ....setting mode 3: 640 480 FS ....using colorsbits of 16 ....calling CDS: ok ....created window@0,0 (640x480) Initializing OpenGL driver ....getting DC: succeeded ....GLW_ChoosePFD( 16, 24, 0 ) ....35 PFDs found ....GLW_ChoosePFD failed ....failed to find an appropriate PIXELFORMAT ....restoring display settings ....WARNING: could not set the given mode (3) ....shutting down QGL ....unloading OpenGL DLL ....assuming '3dfxvgl' is a standalone driver ....initializing QGL ....WARNING: missing Glide installation, assuming no 3Dfx available ....shutting down QGL ----- CL_Shutdown ----- RE_Shutdown( 1 ) ----------------------- GLW_StartOpenGL() - could not load OpenGL subsystem " Apperently checkdisk was bold enough to simply delete these four files: Index entry nvoglnt.dll of index $I30 in file 0x1d points to unused file 0xc958. Deleting index entry nvoglnt.dll in index $I30 of file 29. Index entry resume.el of index $I30 in file 0xc76b points to unused file 0xc959. Deleting index entry resume.el in index $I30 of file 51051. Index entry Unit1.dfm of index $I30 in file 0xc90d points to unused file 0xc95a. Deleting index entry Unit1.dfm in index $I30 of file 51469. Index entry Unit1.pas of index $I30 in file 0xc90d points to unused file 0xc95b. Deleting index entry Unit1.pas in index $I30 of file 51469. This is not enough information for me, I want to know in what folder these files were so I can asses the damage better. Apperently nvoglnt.dll is related to opengl which is now damaged. resume.el ? I have no idea what this is. Maybe a harmless file of somebodie's resume which I got via spam/e-mail... maybe a virus... maybe just a continue file for some program. Unit1.dfm and Unit1.pas is some delphi source code.... I would like to know which one has been deleted since I have many of these files on my PC.... it's probably not an important one... but stilll I would like to make sure. How do I restore my system ? Do I simply install the latest nvidia driver and hope for the best ? How did this happen in the first place ? (I have been playing around with RTCW and a debugger which I shutdown multiple times but I dont think that was dangerous ? ) Some scenerio's 1. Some kind of crash corrupted it 2. Windows xp pro contains a bug somewhere which corrupted it 3. RTCW has a bug somewhere overwriting this file and corrupting it. 4. Somebody broke into the pc and corrupted it on purpose. 5. A virus/worm corrupted it. Is there anything that can be done to make chkdsk give more information and maybe ask me what I want it to do before it does it ? Well so much for that Bye, Skybuck. |
Ads |
#2
|
|||
|
|||
CHKDSK killed my OpenGL subsystem
"Skybuck Flying" wrote in message
... Today when I booted my computer checkdisk ran automatically, "fixed" some errors, and simply rebooted leaving me in a state of cluelessness. Apperently nvoglnt.dll is related to opengl which is now damaged. Sounds like it - nvoglnt sounds like nVidia OpenGL NT driver - and XP is NT5.1. No idea about the other files. How do I restore my system ? Do I simply install the latest nvidia driver and hope for the best ? First run System File Checker, which will restore any missing or damaged XP files. At the Run option in the Start menu type sfc /scannow and then press OK. Have your XP CD at hand. Then reinstall your nVidia drivers. If you're lucky, that'll sort it all out. I wouldn't risk using a Restore Point for 2 reasons: 1) Anything you installed since the last restore point will be lost 2) If the restore point files were damaged, you could end making things worse. How did this happen in the first place ? (I have been playing around with RTCW and a debugger which I shutdown multiple times but I dont think that was dangerous ? ) Either turning the power off before cached updates have been written back to the hard drive, or hard disk could be on the way out. Get the disk utilities for the drive you have from the manufacturers web site and run a few tests. Is there anything that can be done to make chkdsk give more information and maybe ask me what I want it to do before it does it ? Normally chkdsk runs automatically on start up only when XP hasn't been shut down normally. If you look at the text that comes up it does give you an option to skip the checking - if you do this, and XP boots up, you can run a command prompt and type chkdsk to get it to run without fixing anything, it will display what is wrong (you need to run chkdsk /f to tell it to fix any problems, and this will only be done on your system drive on reboot anyway). Dan |
#3
|
|||
|
|||
CHKDSK killed my OpenGL subsystem
"Spack" wrote in message ... "Skybuck Flying" wrote in message ... Today when I booted my computer checkdisk ran automatically, "fixed" some errors, and simply rebooted leaving me in a state of cluelessness. Apperently nvoglnt.dll is related to opengl which is now damaged. Sounds like it - nvoglnt sounds like nVidia OpenGL NT driver - and XP is NT5.1. Yeah No idea about the other files. How do I restore my system ? Do I simply install the latest nvidia driver and hope for the best ? First run System File Checker, which will restore any missing or damaged XP files. At the Run option in the Start menu type sfc /scannow and then press OK. Have your XP CD at hand. Then reinstall your nVidia drivers. If you're lucky, that'll sort it all out. I wouldn't risk using a Restore Point for 2 reasons: 1) Anything you installed since the last restore point will be lost 2) If the restore point files were damaged, you could end making things worse. Well since only the opengl dll was damaged I was lucky and simply installed the latest nvidia drivers and voila it s working again How did this happen in the first place ? (I have been playing around with RTCW and a debugger which I shutdown multiple times but I dont think that was dangerous ? ) Either turning the power off before cached updates have been written back to the hard drive, or hard disk could be on the way out. Get the disk utilities for the drive you have from the manufacturers web site and run a few tests. Well power off and cache stuff I dont think so at least not for the dll... why would anything write to the dll ? Except maybe defrag or repairing the dll or something wacky. Harddisk could be getting old... though I hope not No I dont trust the utilities... I dont wanna erase my harddisk Is there anything that can be done to make chkdsk give more information and maybe ask me what I want it to do before it does it ? Normally chkdsk runs automatically on start up only when XP hasn't been shut down normally. If you look at the text that comes up it does give you an option to skip the checking - if you do this, and XP boots up, you can run a command prompt and type chkdsk to get it to run without fixing anything, it will display what is wrong (you need to run chkdsk /f to tell it to fix any problems, and this will only be done on your system drive on reboot anyway). Well so far it's has not turn out bad... so I will simply let chkdsk continue to run as it is... But at the next sign of trouble... I'm gonna disable it I dont wanna run the risk of losing important files Though I do make backups... good reason to make another backup soon Bye, Skybuck. |
#4
|
|||
|
|||
CHKDSK killed my OpenGL subsystem
"Skybuck Flying" wrote in message
... "Spack" wrote in message ... Either turning the power off before cached updates have been written back to the hard drive, or hard disk could be on the way out. Get the disk utilities for the drive you have from the manufacturers web site and run a few tests. Well power off and cache stuff I dont think so at least not for the dll... why would anything write to the dll ? Except maybe defrag or repairing the dll or something wacky. By not lettin the machine shut down properly you can mess up the MFT (Master File Table) which is an index of all the files on the drive and their locations - it's not the nVidia dll that got messed up, it was the index information, so the index was removed because XP could not reliably be sure of where the file was and where any fragmented pieces might be. MFT corruption is less likely to happen than with FAT or VFAT, but not shutting your PC down correctly always runs the risk of messing something up. Dan |
#5
|
|||
|
|||
CHKDSK killed my OpenGL subsystem
He'll screw around with a debugger but won't trust disk utilities?
DaveL "Skybuck Flying" wrote in message ... "Spack" wrote in message ... "Skybuck Flying" wrote in message ... Today when I booted my computer checkdisk ran automatically, "fixed" some errors, and simply rebooted leaving me in a state of cluelessness. Apperently nvoglnt.dll is related to opengl which is now damaged. Sounds like it - nvoglnt sounds like nVidia OpenGL NT driver - and XP is NT5.1. Yeah No idea about the other files. How do I restore my system ? Do I simply install the latest nvidia driver and hope for the best ? First run System File Checker, which will restore any missing or damaged XP files. At the Run option in the Start menu type sfc /scannow and then press OK. Have your XP CD at hand. Then reinstall your nVidia drivers. If you're lucky, that'll sort it all out. I wouldn't risk using a Restore Point for 2 reasons: 1) Anything you installed since the last restore point will be lost 2) If the restore point files were damaged, you could end making things worse. Well since only the opengl dll was damaged I was lucky and simply installed the latest nvidia drivers and voila it s working again How did this happen in the first place ? (I have been playing around with RTCW and a debugger which I shutdown multiple times but I dont think that was dangerous ? ) Either turning the power off before cached updates have been written back to the hard drive, or hard disk could be on the way out. Get the disk utilities for the drive you have from the manufacturers web site and run a few tests. Well power off and cache stuff I dont think so at least not for the dll... why would anything write to the dll ? Except maybe defrag or repairing the dll or something wacky. Harddisk could be getting old... though I hope not No I dont trust the utilities... I dont wanna erase my harddisk Is there anything that can be done to make chkdsk give more information and maybe ask me what I want it to do before it does it ? Normally chkdsk runs automatically on start up only when XP hasn't been shut down normally. If you look at the text that comes up it does give you an option to skip the checking - if you do this, and XP boots up, you can run a command prompt and type chkdsk to get it to run without fixing anything, it will display what is wrong (you need to run chkdsk /f to tell it to fix any problems, and this will only be done on your system drive on reboot anyway). Well so far it's has not turn out bad... so I will simply let chkdsk continue to run as it is... But at the next sign of trouble... I'm gonna disable it I dont wanna run the risk of losing important files Though I do make backups... good reason to make another backup soon Bye, Skybuck. |
#6
|
|||
|
|||
CHKDSK killed my OpenGL subsystem
"DaveL" wrote in message ... He'll screw around with a debugger but won't trust disk utilities? Nope these utitilities are complex and hard to understand and before you know... you're doing a low level format heheheheh. |
#7
|
|||
|
|||
CHKDSK killed my OpenGL subsystem
"DaveL" wrote in message ... He'll screw around with a debugger but won't trust disk utilities? Yeah.... I'll pass on disk utilities that do a low level format to "test" the drive LOL. Bye. Skybuck |
#8
|
|||
|
|||
CHKDSK killed my OpenGL subsystem
Besides....
I checked this site: http://www.hitachigst.com/hdd/support/download.htm It does mention possibility of losing data... scary. But even if I wanted to give it a go... I dont have a diskdrive anymore hehehehehehe removed yessss to make room for the king the new drive... so it s cooool. I could make a bootable cd... but spending on 1 euro on it is LOL to much what a waste |
#9
|
|||
|
|||
CHKDSK killed my OpenGL subsystem
On Tue, 28 Dec 2004 12:22:34 +0100, "Skybuck Flying"
"Spack" wrote in message "Skybuck Flying" wrote in message Today when I booted my computer checkdisk ran automatically, "fixed" some errors, and simply rebooted leaving me in a state of cluelessness. Two bad OS design "features" at work he 1) Auto-fixing ChkDsk (or really in this case, AutoChk) 2) Automatically reboot on system errors Even if you say "well, unattended servers would want reboot on errors to maintain downtime", what's the point of rebooting on errors that arise before the OS boot process is complete? Fortunately, you can (and IMO should) kill (2) via System, Properties, Advanced etc. Unfortunately, the UI design of ChkDsk and AutoChk date from before MS-DOS 6 brought Scandisk to the world, so they simply don't offer any interactive (user-controlled) mode of operation at all Apperently nvoglnt.dll is related to opengl which is now damaged. Sounds like it - nvoglnt sounds like nVidia OpenGL NT driver - and XP is NT5.1. No idea about the other files. Not only do AutoChk and ChkDsk /F automatically "fix" without prompting you, but they bury their results deep in the bowels of Event Viewer. Not somewhere obvious like "ChkDsk", but "Winlogin" or something. It's hard to read that material if XP can't boot. Well since only the opengl dll was damaged I was lucky and simply installed the latest nvidia drivers and voila it s working again Either turning the power off before cached updates have been written back to the hard drive, or hard disk could be on the way out. Get the disk utilities for the drive you have from the manufacturers web site and run a few tests. why would anything write to the dll ? Except maybe defrag or repairing the dll or something wacky. Yes, code files would normally be written to only when: - installed - updated - infected - disinfected - moved by defrag - "fixed" by ChkDsk or AutoChk - splatted by wild writes HD file system (structure, i.e. that ChkDsk can detect) can be corrupted in various ways: 1) Interruption of sane writes This is what ChkDsk and AutoChk ASSume is going on, when they "fix" things, and what NTFS's vaunted "transaction rollback" is designed to mitigate (though the small print says only metadata is protected). 2) Wild writes If the file system's layer of abstraction is undermined by bad RAM or other flaky hardware, or deranged/malicious software, then the file system's "rules" may be broken too. For example, a data cluster destined for volume cluster address 63412 may be bit-punned (by a reset address bit) to 30644, and thus overwrite data from some completely unrelated file. At the lower level of raw sector addresses, this can corrupt the raw bones of the file system itself. 3) Bad HD Just about everything conspires to hide HD failure from you. First, the HD's own firmware "fixes" rotting sectors on the fly; then NTFS's code does the same thing, and finally ChkDsk /R paints over bad clusters and ignores existing ones. And by default, CMOS setup disables SMART reporting on POST. So it's up to you to suspect this possibility whenever the mouse pointer sticks with the HD LED on (bad sector retries) and chase it up before your data's hosed. On HD diagnostics: Yes, take care to avoid destructive tests, and abort testing as soon as physical errors show up and proceed directly to evacuating your data, from outside "I can't run without writing to C:, too bad if that kills the data" Windows. SMART reporters from HD vendors will look at the SMART history and typically go "hmmm, only a few thousand wobbly sectors that so far we've auto-'fixed'... OK, call it a 'good' HD, no need to issue an RMA". Don't accept a glib one-line "everything's fine" report; use something like AIDA32 to show you all the detail that SMART can cough up. SMART's potentially good in that it's the only window into bad sectors that are already hidden by the firmware's "fixing". In addition, use something that can non-destructively check the HD surface. Watch for slowdowns in the progress - if outside of Windows's constant background tasks, they can be taken to mean retries of sick sectors - even if the utility says everything is "OK". ---------- ----- ---- --- -- - - - - "He's such a character!" ' Yeah - CHAR(0) ' ---------- ----- ---- --- -- - - - - |
#10
|
|||
|
|||
CHKDSK killed my OpenGL subsystem
On Tue, 28 Dec 2004 13:55:00 -0000, "Spack"
By not lettin the machine shut down properly you can mess up the MFT (Master File Table) which is an index of all the files on the drive and their locations - it's not the nVidia dll that got messed up, it was the index information, so the index was removed because XP could not reliably be sure of where the file was and where any fragmented pieces might be. Great logic, eh? "I can't figure out what's going on, so best we just kill, bury and deny anything happened, even if it means this makes it impossible for a tech to fix things and recover data". MFT corruption is less likely to happen than with FAT or VFAT Well, VFAT is the code that manages FATxx, and FATxx doesn't have an MFT. The most crucial file system structure in FATxx is the FAT themselves, and because these are so crucial, FATxx maintains two copies and updates them both within such a small critical period that "mismatched FAT" from interruption of sane file ops is very rare. What does "better" file system NTFS do about hedging against interrupted MFT updates? AFAIK, nothing beyond keeping duplicates of a handful of crucial system entries. It's a case of the OS saying "I'm alright Jack; too bad about your data". not shutting down correctly always runs the risk of messing up. Yep. Forget that at your peril ;-) --------------- ----- ---- --- -- - - - Tech Support: The guys who follow the 'Parade of New Products' with a shovel. --------------- ----- ---- --- -- - - - |
#11
|
|||
|
|||
CHKDSK killed my OpenGL subsystem
cquirke (MVP Win9x) wrote:
Well, VFAT is the code that manages FATxx, and FATxx doesn't have an MFT. The most crucial file system structure in FATxx is the FAT themselves, and because these are so crucial, FATxx maintains two copies and updates them both within such a small critical period that "mismatched FAT" from interruption of sane file ops is very rare. What does "better" file system NTFS do about hedging against interrupted MFT updates? AFAIK, nothing beyond keeping duplicates of a handful of crucial system entries. It's a case of the OS saying "I'm alright Jack; too bad about your data". NTFS is journalled, so if any sequence of file system operations was interrupted there should be a record of what was being done in the journal so that the missing operations can be reconstructed. Therefore there should be no way for the file system structure to become corrupted due to an unclean shutdown. Normally a full chkdsk is not necessary in this situation since the journal can be quickly replayed. I suspect in this case something else happened to cause some on-disk corruption of the file system data structures.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from Home Page: http://www.roberthancock.com/ |
#12
|
|||
|
|||
CHKDSK killed my OpenGL subsystem
On Wed, 29 Dec 2004 17:54:09 GMT, Robert Hancock
cquirke (MVP Win9x) wrote: What does "better" file system NTFS do about hedging against interrupted MFT updates? AFAIK, nothing beyond keeping duplicates of a handful of crucial system entries. It's a case of the OS saying "I'm alright Jack; too bad about your data". NTFS is journalled, so if any sequence of file system operations was interrupted there should be a record of what was being done in the journal so that the missing operations can be reconstructed. What specifically does journalling keep a backup of, that it can undo? I ask, for two reasons: 1) MS's documentation suggests only metadata is preserved 2) Performance impact implies data cluster chains aren't duplicated For example; I add two bytes at offset 37600 in a 125000567-byte file. If journalling was to *totally* preserve the state of the original file, it would have to retain all clusters from the original file from that containing the offset, onwards, plus the original dir entry, plus the old chaining info (which as I understand it, is not a "FAT" but a set of start addresses for the cluster runs that make up the file). Is this what journalling does? Or something rather less than this? Therefore there should be no way for the file system structure to become corrupted due to an unclean shutdown. I suspect the devil may be in the details on this one ;-) Normally a full chkdsk is not necessary in this situation since the journal can be quickly replayed. Sometimes, you may *want* the broken remains of the file that was being created or updated, which journalling is likely to throw away. If you disable AutoChk, does that also disable the journalling "automatic fixing" feature as well? I suspect in this case something else happened to cause some on-disk corruption of the file system data structures. That's my suspicion, too. These things happen, and when they do, NTFS is far less fixable (in the sense of "preserve or recover my files" rather than "do whatever it takes to sanify the file system") --------------- ----- ---- --- -- - - - Never turn your back on an installer program --------------- ----- ---- --- -- - - - |
#13
|
|||
|
|||
CHKDSK killed my OpenGL subsystem
cquirke (MVP Win9x) wrote:
On Wed, 29 Dec 2004 17:54:09 GMT, Robert Hancock cquirke (MVP Win9x) wrote: What does "better" file system NTFS do about hedging against interrupted MFT updates? AFAIK, nothing beyond keeping duplicates of a handful of crucial system entries. It's a case of the OS saying "I'm alright Jack; too bad about your data". NTFS is journalled, so if any sequence of file system operations was interrupted there should be a record of what was being done in the journal so that the missing operations can be reconstructed. What specifically does journalling keep a backup of, that it can undo? I ask, for two reasons: 1) MS's documentation suggests only metadata is preserved 2) Performance impact implies data cluster chains aren't duplicated For example; I add two bytes at offset 37600 in a 125000567-byte file. If journalling was to *totally* preserve the state of the original file, it would have to retain all clusters from the original file from that containing the offset, onwards, plus the original dir entry, plus the old chaining info (which as I understand it, is not a "FAT" but a set of start addresses for the cluster runs that make up the file). Is this what journalling does? Or something rather less than this? In the case of NTFS I believe that only file system metadata is preserved, i.e. the file system is guaranteed to be consistent, however files that were being written at the time of the crash could contain old data, new data, or a mixture of the two. There are some other file systems that have stronger guarantees (Reiser4 on Linux is claiming to have all file system operations fully atomic with no performance hit, and I believe even ext3 has better guarantees than this by default). Even in those cases though, the operation you describe wouldn't be atomic, since that can't be done through a single file system operation (you can't just tell the OS to insert data in the middle of a file, you have to write the new data and then move the rest of the contents down yourself). -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from Home Page: http://www.roberthancock.com/ |
#14
|
|||
|
|||
CHKDSK killed my OpenGL subsystem
On Sat, 01 Jan 2005 07:58:43 GMT, Robert Hancock
cquirke (MVP Win9x) wrote: On Wed, 29 Dec 2004 17:54:09 GMT, Robert Hancock NTFS is journalled, so if any sequence of file system operations was interrupted there should be a record of what was being done in the journal so that the missing operations can be reconstructed. What specifically does journalling keep a backup of, that it can undo? 1) MS's documentation suggests only metadata is preserved 2) Performance impact implies data cluster chains aren't duplicated In the case of NTFS I believe that only file system metadata is preserved, i.e. the file system is guaranteed to be consistent, however files that were being written at the time of the crash could contain old data, new data, or a mixture of the two. Well, that's the point. What you are saying is that the NTFS journalling feature does absolutely nothing to preserve your data. Even in those cases though, the operation you describe wouldn't be atomic, since that can't be done through a single file system operation (you can't just tell the OS to insert data in the middle of a file, you have to write the new data and then move the rest of the contents down yourself). Quite. What you'd have to do, if you wanted to claim perfect preservation of the previous state, is to write the new material to unused clusters, then chain these into place, and finally update the dir entry to point to the new form of the file as an atomic operation. I'd do that by first adding the chain as am ADS, and then switching pointers so that it becomes the main data stream, then I'd drop and unlink the old version of the file. But the performance impact could be really ugly, and one of the drawbacks being you'd need space for both new and old file chains. In practice, MS is not concerned with your data at all; only the sanity of the file system. After all, the only impact these matters have on MS is in terms of support calls. No vendor assumes any responsibility for your data, so from their perspective, it's irrelevant. From your perspective, it's the only unique part of the system that cannot be restored by throwing money at new parts. The trouble is, these matters will only come to a head when things go wrong. Even then, the user has to believe what the tech says, and many techs are insufficiently skilled or concerned about data recovery. So bogus claims like "NTFS saves you from data loss because of journalling and transaction rollback" are rarely challenged. --------------- ----- ---- --- -- - - - Tech Support: The guys who follow the 'Parade of New Products' with a shovel. --------------- ----- ---- --- -- - - - |
#15
|
|||
|
|||
CHKDSK killed my OpenGL subsystem
cquirke (MVP Win9x) wrote:
In practice, MS is not concerned with your data at all; only the sanity of the file system. After all, the only impact these matters have on MS is in terms of support calls. No vendor assumes any responsibility for your data, so from their perspective, it's irrelevant. From your perspective, it's the only unique part of the system that cannot be restored by throwing money at new parts. The trouble is, these matters will only come to a head when things go wrong. Even then, the user has to believe what the tech says, and many techs are insufficiently skilled or concerned about data recovery. So bogus claims like "NTFS saves you from data loss because of journalling and transaction rollback" are rarely challenged. I think that the main claimed advantage of NTFS journaling is that it avoids the need for a full chkdsk after an unclean shutdown. This is not such a big deal for a home system, but if you have a server containing hundreds of user profiles and many thousands of files, the time it takes to run a full file system check is very significant (many hours in some cases, apparently), during which time the server is not available. There are some advantages as far as data integrity however - in FAT32, etc. there are probably some cases where the file system state after a crash can't be reconciled properly and some files end up orphaned or lost, NTFS would prevent this from happening. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from Home Page: http://www.roberthancock.com/ |
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
chkdsk errors, but chkdsk /f doesn't fix them | Charles Rogers | Performance and Maintainance of XP | 2 | December 21st 04 09:22 PM |
CHKDSK simply doesn't work AGAIN | Scott Lansbury | Performance and Maintainance of XP | 2 | December 4th 04 08:28 PM |
XP / NTSF ...security descriptor / MFT error... | RJK | General XP issues or comments | 3 | November 11th 04 06:59 PM |
Chkdsk errors in SP2 installation | Sam | Windows Service Pack 2 | 8 | October 2nd 04 02:27 AM |