Surendra Verma, Development Manager on the Vista Kernel team, digs into Vista's new Transactional File System with Charles Torre. TxF, as it is referred to internally, is a new kernel construct that is part of an updated Vista NTFS. Surendra provides a high level overview of TxF in this video. Elsewhere, Microsoft is serious about meeting its ship date for Windows Vista during the second half of 2006.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-09-14
Are you retarded or something?
Making low level file system operations atomic (journalling) is very different from full user-api transaction support - making a set of high level operations (file creation, file modification, file copying, file deleting) atomic.
If you want to write a new copy of A.txt over an existing copy of A.txt, a journaling file system does not protect you from the system crashing whilst you write the new copy (leaving you with a half written copy of the new A.txt and losing the entirety of the old A.txt). The "safer" but not absolutely safe way of doing it today would be to write to a temp file and then do a delete/rename.
A transactional file system would ensure that the entirety of the new "A.txt" is written (no matter how many write/read/etc operations it takes) before changes to "A.txt" are made visible.
Of course, a TxFs would allow also allow transactions on more than just a single file.
Edited 2005-12-04 07:39
Member since:>Are you retarded or something?
No, I study filesystems.
>Making low level file system operations atomic
>(journalling) is very different from full user-api
>transaction support - making a set of high level
>operations (file creation, file modification, file
>copying, file deleting) atomic.
It's not very different. It's exactly the same thing. Journalling is just a different name for the transaction manager. The set of operations that will take place are written to a journal before being carried out. If the system crashes and no "commit" was received in the journal, then the operation is either rolled back or replayed upon reboot. The high-level operations are the most basic file manipulation operations, and without and API for those (read(), write()) no-one could write to the filesystem.
>If you want to write a new copy of A.txt over an
>existing copy of A.txt, a journaling file system does
>not protect you from the system crashing whilst you
>write the new copy (leaving you with a half written
>copy of the new A.txt and losing the entirety of the
>old A.txt). The "safer" but not absolutely safe way
>of doing it today would be to write to a temp file
>and then do a delete/rename.
A journaling filesystem does exactly that. Have another read here:
http://en.wikipedia.org/wiki/Journaling_filesystem
>A transactional file system would ensure that the
>entirety of the new "A.txt" is written (no matter how
>many write/read/etc operations it takes) before
>changes to "A.txt" are made visible.
Again, read the wikipedia article and get a little bit of a clue.
Member since:
or even here:
http://en.wikipedia.org/wiki/Journaling_filesystem
(excerpt:
Another way to recover is for the file system to keep a journal of the changes it intends to make, ahead of time. Recovery then simply involves re-reading the journal and replaying the changes logged in it until the file system is consistent again. In this sense, the changes are said to be atomic (or indivisible) in that they will have either:
* Have succeeded originally.
* Be replayed completely during recovery.
* Not be replayed at all.
)
hmmm... that sounds familiar...