Actually there are two meanings attached to it:
A FileSystem, that supports TransactionProcessing, i.e. .
Contrary to most databases, I do not know of any, but wish, there were some. Can you help?
Wouldn't it be more prudent just to switch to a database if such features are required?
ItDepends: The choice should depend on the kind and structure of the data stored, shouldn't it?
Alternatively you can have a database that provides a FileSystem. Oracle has a product called "Internet File System" who does just that, but how good that is is anybody's guess as references to it are rare (anybody has any in-depth info ?).
The reason why TransactionalFileSystem in this sense is not given much attention by file system implementors is that even if FileSystem would provide for "transactions", the API exposed by a file system (open, read, write, seek, close) is so low level that it can rarely be used as such by application involved in typical data processing, and it would also be expensive to implement. So the cost/benefit trade-off does not drive the open-source commercial community to look into this area.
I concede, that some idiom would be required to demarkate TransactionBoundary?s if the transaction should include more than one file.
Datalight (http://www.datalight.com) does such a file system for embedded applications, called Reliance.