Managed World

Techno-babble from yet another babbler RSS 2.0
# Wednesday, April 04, 2007

Andrew recently watched my screencasts and had some great questions that came up around how Transactional NTFS behaves with the file system. So, I figured I would answer them here. So, if you want to see the context around his questions, check out his post.

Here's the paragraph with the questions:

I wonder what happens to files that never get committed - ala a long running transaction. They have to be taking up file space. Jason says not even Windows Explorer knows about them, but they have to exist somewhere. What if they overflow? Is there a way to clean house? If the poop is invisible, does it still stink?

Great observations and questions Andrew! In the case of a long running, open transaction, the files will exist on the disk. Hence, they are certainly taking up space on the disk. If you have 256 MB of free space on your disk, and try to write 257 MB of data to the disk within a transaction, you will get an "out of space" error like you would outside of a transaction.

Is there a way to clean house? Yes, rollback or commit the transaction. On rollback, any changes made within the transaction are rolled back, and then consequently removed form the disk.

But what if my server crashes in the middle of a transaction. Would I have turds floating around the file system? No, you would not. When an NTFS-formatted volume is mounted in Vista or Windows Server "Longhorn", any transactions that are "in-doubt" (the transaction manager is no longer around and we have no clue on the status of the transaction) will be rolled back automatically, effectively removing all the changes from disk. So, in that sense, you would not have any file turds you have to clean up after a system crash (like you would have if you were doing a "temp file -> rename" type of methodology.

Now, as is usual in transaction systems, you have to be _very_ aware and _very_ cautious of long-running transactions as it could cause some long-term problems that you don't want to deal with. So, there certainly are scenarios where Transactional NTFS just is not a good fit. As tends to be the case with all technology, make sure you are using the right tool for the right job :).

 #       Comments [3]
Wednesday, April 04, 2007 7:10:07 PM (Pacific Standard Time, UTC-08:00)
Ok, I don't have the bits installed so I have to ask the question.

Thread safety?

What happens if you start a transaction in one thread with plenty of disk space and start streaming data to the filesystem, then another thread comes along and gobbles up all your free disk space and commits. When does the first thread receive the notice that there's no more disk space? Upon commit of the transaction I would think. (thinking of streaming media applications or bittorrent clients here)
Thursday, April 05, 2007 1:52:54 AM (Pacific Standard Time, UTC-08:00)
I think the first transaction would abort midway since the log file system would suddenly find itself dumb out of disk space spank in the middle of saving a log entry.
Thursday, April 05, 2007 7:45:27 AM (Pacific Standard Time, UTC-08:00)
Yes, I believe Ranju is correct on this one. Even if a transaction is "in process", additions made to the file system still get written to the file system (it has to go somewhere). The second the disk fills up, you get the "out of space" exception and hence the transaction would roll back (the first one).

Transactional NTFS is optimized for commit. This means that when you are writing data to the file system within a transaction, the data is physically being written to the file system. It does not wait for a commit to do the writing to the file system (which could incur a big performance hit). So, the second the disk fills up, the data being added within the first transaction will fail.
Name
E-mail
Home page

Comment (Some html is allowed: a@href@title, strike) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

Live Comment Preview

Contact

Email Me Send mail to the author(s)

Calendar

<October 2008>
SunMonTueWedThuFriSat
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678

About this site

Jason Olson's thoughts on Programming, Games, Music and Life in General

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2008
Jason Olson

Sign In
All Content © 2008, Jason Olson
Theme based on 'Business' created by Christoph De Baene (delarou)