Linked by Eugenia Loli on Sat 3rd Dec 2005 19:41 UTC
Windows 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.
Thread beginning with comment 69508
To read all comments associated with this story, please click here.
Keep the questions coming :)
by malxau on Wed 7th Dec 2005 04:30 UTC
malxau
Member since:
2005-12-04


Do you block? If so, do you have dead-lock detection?
Please elaborate.


No. Only one transaction can modify a single file at the same time. If another transaction attempts to modify the same file, the second caller will fail with ERROR_SHARING_VIOLATION. If two transactions are creating a new file with the same name (the file is not visible to the second transaction), the second caller will receive ERROR_TRANSACTIONAL_CONFLICT.


Do you fail-fast? If so, is first-come the champion?
Please elaborate.


I guess so; the second caller can decide what actions to take in this case.


And finally, what of applications not using tx-semantics? How do they fare against applications
tx'ing.


The idea is to preserve compatibility. If a non-tx app creates a new file, for example, all other apps can now 'see' the file. If a tx app creates a new file, it is not visible until commit. However, if a non-tx app attempts to modify a file that an unresolved tx has modified, it will fail as above.


Is each fs-op then considered a xaction?


No - the caller controls where transactions are started, committed, or rolled back.


If this is the case, what is the performance
impact on fs-op considering the overhead?


Tx operations are obviously slower than non-tx operations. Our goal has been to not regress the non-tx case, and to keep the tx case as good as we can.


Will TxF be turned on by default for all file system ops?


Txf is controlled by the caller. It will be available on NTFS on Vista. You won't need to do anything to enable it; however, file system ops aren't updated to use it 'automatically.' The caller controls what happens.


I hope you will include support for well-behaved legacy Win32 apps, so that early adopters see immediate benefits moving to Vista.


I hope so too. The problem is, how do you know if a legacy app is "well-behaved" or not? Badly behaved apps can really make a mess.

If you're an MSDN subscriber, our current builds support the following on the command line:
transaction /start
legacyapp1.exe
legacyapp2.exe
transaction /commit


Can you have a compatibility DLL that converts all but the lowest level file ops to use proper calls to TxF?


We currently do this with an "implicit" development model. An app calls SetCurrentTransaction(), and all file system calls will use that transaction, until the app calls SetCurrentTransaction() again, either for a new transaction, or back to non-tx. Once a file is opened with a transaction, all operations to that handle will use the transaction.


Will ALL dotNet 2+ CLR apps use TxF under Vista?


They can, but the application has to request to use transactions.


Txf is a layer on top of NTFS.


Txf is an integral part of NTFS. On Vista, if you have NTFS, you have transaction support.


So will that affect performance of applications in terms of I/O?


Yes, unfortunately. This isn't really avoidable given the additional guarantees transactions make. However, it should perform better than any application-level solution to this problem.


Will the fragmentation of disk be avoided or bettered?


It shouldn't really change either way. Since only one transaction can modify a file at any point in time, the allocation semantics are essentially the same.


Will adding another layer of code *in between* affect performance again?


It's not really another layer; performance won't go down on account of Txf's design.


Of what importance is a transactional file system in a computer used in a home/office environment?


Applications will use it. For example, Windows update uses it. Down the track, the uses are infinite. Maybe a music player that updates its playlist and the files on disk in a transaction to ensure they're in sync. Or an uncompression tool that succeeds or fails atomically. Any multi-file updates, or single file in conjunction with some other service, can benefit from this. Which ones you might encounter in a home/office environment depends how you use your home/office computer ;) .

Reply Score: 1

Aparan Member since:
2005-10-14

The fool again,

From what you said:

In Vista TxF support exists side by side with NTFS. Apps are at their will to use the *real* NTFS or NTFS with TxF support.

You said that TxF will be slower that regular disk I/O. Again you are saying that performance will not be affected. Also you said TxF is *integral* to NTFS. If that is the case, can the future apps with TxF support do xActions in a WinXP or win2k running on NTFS? I doubt this.

I would again say that performance would be hit if an app is to use xActions for all kind of disk I/O. Someone was earlier comparing it to RDBMS. RDBMS uses xActions, but ultimately it ends in regular kind of disk read/write. So that would not be a good comparison to make for transactions at FileSystem level. Please enlighten me if I am wrong.

Lastly, I would say that in Windows the performance hit due to fragmentation is quite large (especially in computers with a little RAM (256 or so) and when 'thrashing' occurs you can *feel* it. So this is a major issue that Vista *should* have addressed. But...

Reply Parent Score: 1

tummy Member since:
2005-09-14


. Someone was earlier comparing it to RDBMS. RDBMS uses xActions, but ultimately it ends in regular kind of disk read/write.


WTF are you going on about? FS transactions end up in a "regular kind of disk read/write" too.

Are you cliaming that databases can do something special that file systems can't (even though file systems are lower level)? Hell, Oracle basically is its own file system when used in full partition mode. According to you, it would would run slower in that mode. Isn't that right?

Why is this thread full people who talk out of their ass?

Edited 2005-12-07 05:47

Reply Parent Score: 1