Re: the file writing consistency About Windows' NTFS
From: Tim (Tim_at_NoSpam)
Date: 02/16/04
- Next message: crimson13: "Re: menu in a dialogbar"
- Previous message: X.H.Qiu: "the file writing consistency About Windows' NTFS"
- In reply to: X.H.Qiu: "the file writing consistency About Windows' NTFS"
- Next in thread: X.H.Qiu: "Re: the file writing consistency About Windows' NTFS"
- Reply: X.H.Qiu: "Re: the file writing consistency About Windows' NTFS"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 16 Feb 2004 21:58:06 +1300
Hi,
>From the book "Inside the Windows NT File System" MS Press:
"NTFS uses the transaction processing moidel to implement its file system
recovery feature. If a program initiates an I/O operation that alters the
structure of the NTFS file system - changes directory structure, extends a
file, allocates space for a new file, and so on - NTFS treats the operation
as an atomic transaction. It guarantees that the transaction is either
completed or, if the system fails while executing the transaction, rolled
back. ....."
the book goes on for around 100 pages detailing how this works, along with
how fault tolerance and compression is implemented.
You do not need to do anything with an NTFS formatted disc for all this to
operate. The only provision I would place on this is that if you are using a
caching raid controller, ensure that it is Windows HCL certified, or it is
on a UPS or has Write caching turned off since the unwritten contents of the
controller cache memory are unknown to Windows - this is a problem only on
"some" caching RAID controllers and hopefully no longer occurs with recent
models. Modern IDE RAID controllers are usually not caching controllers,
although the better ones are.
There has been one NTFS related bug I recall recently where on extremely
fast systems if a very substantial numer of changes occur in rapid
succession, the log file (journal) can overflow. There is a patch for this.
If you wish to recover a file you have deleted, then please look for an
UnDelete utility. Nesting does not occur - if the log file runs out of space
you will get a Windows error message "Log File Full" - again, extremely
rare. During an orderly shutdown the log on the disc volumes are
checkpointed and the discs marked 'clean'. In the event of a failure, then
system 'replays' the contents of the log to since the last checkpoint to
ensure that all transactions are applied correctly.
Note: NTFS does not guarantee the integrity of user data - it can't, but it
does guarantee the integrity of its own structure although there is
provision in the design of the file store for this future capacity.
If you are having trouble with NTFS or are curious then perhaps flick over
to one of the Microsoft newsgroups and post a specific query there. More
information is at http://msdn.microsoft.com or http://support.microsoft.com
HTH
- Tim
"X.H.Qiu" <qiuxh@sz.cathay.jp> wrote in message
news:eB2eWbG9DHA.1804@TK2MSFTNGP12.phx.gbl...
> Hello!
>
> NTFS is transaction log file system. For becoming a recoverable file
system,
> it use the following ways:
> 1.to use cash buffer.
> 2.In order to recover those files which are destoried, use transaction log
> file to record those operations on files.
>
> But about above, I have a question as follows:
> How to make transaction log files recoverable after they being destoried?
> Use another transaction log files? if this is true, nesting will occured,
> won't it?
>
> look forward to your answers!
>
> thanks
>
> with the best wish!
>
> X.H.Qiu
>
>
- Next message: crimson13: "Re: menu in a dialogbar"
- Previous message: X.H.Qiu: "the file writing consistency About Windows' NTFS"
- In reply to: X.H.Qiu: "the file writing consistency About Windows' NTFS"
- Next in thread: X.H.Qiu: "Re: the file writing consistency About Windows' NTFS"
- Reply: X.H.Qiu: "Re: the file writing consistency About Windows' NTFS"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|