Re: CHKDSK killed my OpenGL subsystem
From: Robert Hancock (hancockr_at_nospamshaw.ca)
Date: 01/01/05
- Next message: Mark Frymier: "Re: create bootable/recovery CD, and also carve partions into C dr"
- Previous message: Will Denny: "Re: Repair .dll files?"
- In reply to: cquirke (MVP Win9x): "Re: CHKDSK killed my OpenGL subsystem"
- Next in thread: cquirke (MVP Win9x): "Re: CHKDSK killed my OpenGL subsystem"
- Reply: cquirke (MVP Win9x): "Re: CHKDSK killed my OpenGL subsystem"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 01 Jan 2005 07:58:43 GMT
cquirke (MVP Win9x) wrote:
> On Wed, 29 Dec 2004 17:54:09 GMT, Robert Han***
>
>>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 Han*** Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthan***.com/
- Next message: Mark Frymier: "Re: create bootable/recovery CD, and also carve partions into C dr"
- Previous message: Will Denny: "Re: Repair .dll files?"
- In reply to: cquirke (MVP Win9x): "Re: CHKDSK killed my OpenGL subsystem"
- Next in thread: cquirke (MVP Win9x): "Re: CHKDSK killed my OpenGL subsystem"
- Reply: cquirke (MVP Win9x): "Re: CHKDSK killed my OpenGL subsystem"
- Messages sorted by: [ date ] [ thread ]