-
Notifications
You must be signed in to change notification settings - Fork 0
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
Update TxnLogger to use uuid_t #15
base: tc-server-2.7
Are you sure you want to change the base?
Conversation
assert(nfs_vunlink_to_txnlog(arg, &txn_log) == 0); | ||
break; | ||
case txn_VRename: | ||
case txn_VMkdir: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mkdir
and symlink
are actually CREATE
operations
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is more inline with vNFS client.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well but this is not consistent with get_txn_type()
because it won't return VMkdir
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about if we even plan to support VMkdir, since it seems to serve same purpose as VCreate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah so we can just keep VCreate and discard VMkdir and VSymlink
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The vNFS client actually has both operations, I have to see if they are being used or not before removing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But mkdir
and symlink
in the client side are finally translated into CREATE
, aren't they? If get_txn_type()
doesn't return VMkdir
by inspecting arguments of opcreate
structure, there is no point having case txn_VMkdir
here.
@@ -196,8 +194,8 @@ void serialize_unlink_txn(struct TxnLog *txn_log, | |||
struct UnlinkId *txnobj = &txn_log->created_unlink_ids[i]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that txn_log->backup_dir_path
is not initialized before, so the system will abort with SIGSEGV. Did you run tests?
strcpy(object.name, absl::StrJoin(path_components, "/").c_str()); | ||
created_unlink_ids.push_back(object); | ||
} else { | ||
std::cerr << "Unknow operation for VRemove: " << ops[i].argop; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please also consider GETATTR
, SAVEFH
and other auxiliary operations. Also I'm not sure if std::cerr
can write message into the log file.
for (int i = 0; i < ops_len; ++i) { | ||
if (ops[i].argop == NFS4_OP_CREATE) { | ||
txn_type = proto::TransactionType::VCREATE; | ||
if (ops[i].argop == NFS4_OP_CREATE && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also need to recognize NFS4_OP_OPEN
where new files may be created or existing files can be truncated.
Also, added some simple tests for creating TxnLog from nfs compound