Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inquiry Regarding txid Passing in ccNVMe #1

Open
zeyvier opened this issue Dec 19, 2023 · 3 comments
Open

Inquiry Regarding txid Passing in ccNVMe #1

zeyvier opened this issue Dec 19, 2023 · 3 comments

Comments

@zeyvier
Copy link

zeyvier commented Dec 19, 2023

Issue Title: Inquiry Regarding txid Passing in ccNVMe


Description

I have recently had the opportunity to explore your article on "Crash Consistent Non-Volatile Memory Express," and I am genuinely fascinated by the methodologies outlined in the piece. Subsequently, I downloaded the corresponding source code for the project to gain a deeper understanding.

In the article, there is a mention of txid as a pivotal identifier for transactions, crucial for maintaining data consistency across multiple levels of the IO stack during normal write operations and recovery processes. However, while examining the current source code, I observed that txid is generated in ext4_sync_file and ext4_atomic_file and appears to be passed down by calling STREAM_COMMIT_TX(stream, txid).

Upon further inspection into the implementation of STREAM_COMMIT_TX and its specific counterpart, stream_tx_commit_core (source code link), I noticed that the txid parameter is accepted, but its utilization within the function seems to be absent.

In my attempt to trace the path of txid from the upper file system layer to the lower layers, I couldn't find any other instances. Consequently, I would like to humbly seek your guidance on the specific methodology employed in this project for passing txid from the upper file system layer to the lower layers.

I am genuinely grateful for your time and assistance.

@liaoxiaojian
Copy link
Collaborator

In our implementation, the txid is not passed across various layers. Instead, it's directly passed to the ccnvme module (see Figure 9 of the paper) and stored in the PMR.

If you want to pass the txid across the I/O stack, I think the best way is to record the txid in the bio->bi_private field and pass it to the block layer via submit_bio.

@zeyvier
Copy link
Author

zeyvier commented Dec 20, 2023

In our implementation, the txid is not passed across various layers. Instead, it's directly passed to the ccnvme module (see Figure 9 of the paper) and stored in the PMR.

If you want to pass the txid across the I/O stack, I think the best way is to record the txid in the bio->bi_private field and pass it to the block layer via submit_bio.

Thank you for your response. I may not have been very clear in my previous explanation, but I still have a question regarding the issue. I noticed that the txid is generated in the /mqfs/fsync.c file within the ext4_sync_file and ext4_atomic_file functions using the following statement:

txid = atomic_inc_return(&EXT4_SB(inode->i_sb)->txid_alloc);

This txid, as you mentioned, should be passed to the ccnvme module through STREAM_COMMIT_TX (tracing it further, it eventually reaches stream_tx_commit_core). STREAM_COMMIT_TX is the only place where txid is used in ext4_sync_file. However, although the stream_tx_commit_core function has a parameter for txid, it seems that txid is not referenced within stream_tx_commit_core. It appears that the propagation of txid stops in this function. Therefore, I would like to know how exactly the txid is being passed to the ccnvme module.

Thank you in advance for your assistance.

@liaoxiaojian
Copy link
Collaborator

When stream_tx_commit_core is invoked, the process is already in the ccnvme module, which stores txid in the struct nvme_rw_command_ to emulate an entry of the NVMe SQ.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants