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

[feat]curvefs/client:support warmup to disk/mem #2341

Merged
merged 1 commit into from Apr 17, 2023

Conversation

Cyber-SiKu
Copy link
Contributor

What problem does this PR solve?

Issue Number: #xxx

Problem Summary:

What is changed and how it works?

What's Changed:

How it Works:

Side effects(Breaking backward compatibility? Performance regression?):

Check List

  • Relevant documentation/comments is changed or added
  • I acknowledge that all my contributions will be made under the project's license

}
return ret;
}

using ::curve::common::StringToUll;

// if direction is true means '+', false means '-'
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.

  1. It looks like the code is written in c++, but there is no include file for c++ library.
  2. The code doesn't check for empty string.
  3. The code doesn't handle any exception if the input string is invalid.
  4. The code should be tested for different inputs and proper error messages should be handled.
  5. The code has a lot of hard coded strings which can be replaced with constants.
  6. The function GetWarmupStorageType() should also have a default return value in case none of the conditions are met.

kWarmupStorageTypeKvClient = 2,
};

WarmupStorageType GetWarmupStorageType(const std::string &type);

enum class FileHandle : uint64_t {
kDefaultValue = 0,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

with code review:

  1. The code looks syntactically correct, however, it could be improved by adding more comments to explain the purpose of each enumeration and function.
  2. It could also be improved by adding input validation to ensure that the type string is a valid type and that the function is returning the correct storage type.
  3. Another improvement would be to make sure that the enum values are consistent across the different enumerations.

int ret = 0;
switch (curvefs::client::common::GetWarmupOpType(opTypePath[0])) {
case curvefs::client::common::WarmupOpType::kWarmupOpAdd:
ret =
AddWarmupTask(curvefs::client::common::GetWarmupType(opTypePath[1]),
key, opTypePath[2]);
key, opTypePath[2], storageType);
if (ret != 0) {
LOG(ERROR) << name << " has invalid xattr value " << value;
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

our code review.

  1. The code patch seems to be adding a new argument 'storageType' to two existing functions AddWarmupTask and Warmup. This is good as it increases the flexibility of the functions.

  2. The code patch also checks the validity of the size of the value passed to the Warmup function, which is also a good practice.

  3. The code patch also checks for the storage type of the value passed to the Warmup function, which is a great addition.

  4. There are no obvious bugs in the code, however I would recommend that you add more tests to make sure that the changes are working as expected.

Overall, this looks like a good code patch. Good job!

if (fsInfo_->fstype() == FSType::TYPE_S3) {
return warmupManager_->AddWarmupFile(key, path);
return warmupManager_->AddWarmupFile(key, path, type);
} // only support s3
return true;
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

!

There are two major changes in the code patch:

  1. Adding optional parameter "type" to PutWarmFilelistTask and PutWarmFileTask functions.
  2. Replacing warmupManager_->AddWarmupFilelist and warmupManager_->AddWarmupFile with warmupManager_->AddWarmupFilelist and warmupManager_->AddWarmupFile respectively.

From the code, it looks like all the parameters are valid and there are no obvious bugs. However, I suggest that you should add some input validation checks for the new parameter 'type', in order to ensure that only valid values are passed. Also, you should add some unit tests to test the functionality of the changes you have made.

void PutObjectToCache(const std::string &filename, const char *data,
uint64_t len);
void PutObjectToCache(fuse_ino_t key, const std::string &filename,
const char *data, uint64_t len);

protected:
std::deque<WarmupFilelist> warmupFilelistDeque_;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the code review

  1. Include proper headers:
    • The code includes the common.h header which is good, however it should also include the relevant .h files for the used classes like DentryCacheManager, InodeCacheManager and WarmupFile.
  2. Class WarmupProgress:
    • The constructor declaration should include a default value for the storageType parameter
  3. AddWarmupProcess method:
    • The method should include a parameter for the type of warmup storage to be used.
  4. AddWarmupFilelist and AddWarmupFile methods:
    • Both of these methods should include a parameter for the type of warmup storage to be used.
  5. PutObjectToCache method:
    • The method should include a parameter for the key of the cache entry to be added.

@@ -185,7 +198,7 @@ func (aCmd *AddCommand) RunCommand(cmd *cobra.Command, args []string) error {
}
xattr = CURVEFS_WARMUP_OP_ADD_LIST
}
value := fmt.Sprintf(xattr, aCmd.CurvefsPath)
value := fmt.Sprintf(xattr, aCmd.CurvefsPath, aCmd.StorageType)
err := unix.Setxattr(aCmd.Path, CURVEFS_WARMUP_OP_XATTR, []byte(value), 0)
if err == unix.ENOTSUP || err == unix.EOPNOTSUPP {
return fmt.Errorf("filesystem does not support extended attributes")
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

with a brief overview of this code patch. Here, a command is being added to add warmup files in a given path to Curvefs. The code creates two constants CURVEFS_WARMUP_OP_XATTR and CURVEFS_WARMUP_OP_ADD_SINGLE/CURVEFS_WARMUP_OP_ADD_LIST which are used to store the values for the xattr and warmup operations. A variable STORAGE_TYPE is also created to store the supported storage types. A struct AddCommand is then defined which stores the necessary data for the command. Finally, the code implements the Init and RunCommand functions for the command which are used to process the input parameters and run the command.

From a code review perspective, I suggest the following changes:

  1. Add more comments to explain the purpose of the code and clarify the logic flow.
  2. Improve error handling by adding checks for invalid input parameters.
  3. Add more tests to ensure that the command behaves as expected.

func GetStorageFlag(cmd *cobra.Command) string {
return GetFlagString(cmd, CURVEFS_STORAGE)
}

/* required */

// copysetid [required]
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

brief code review:

  1. It looks like the patch code is adding a new flag for storage, is this correct? If yes, it's great to have a brief description of the storage option when calling the command, this can help user understand what type of storage they can choose.
  2. Make sure the default value for storage is valid and reasonable, if the user not provide any input, the system won't crash.
  3. Consider adding more test cases to make sure the new option works correctly.

@Cyber-SiKu
Copy link
Contributor Author

cicheck

@Cyber-SiKu
Copy link
Contributor Author

cicheck

3 similar comments
@Cyber-SiKu
Copy link
Contributor Author

cicheck

@Cyber-SiKu
Copy link
Contributor Author

cicheck

@Cyber-SiKu
Copy link
Contributor Author

cicheck

@Cyber-SiKu
Copy link
Contributor Author

cicheck

1 similar comment
@Cyber-SiKu
Copy link
Contributor Author

cicheck

@Cyber-SiKu
Copy link
Contributor Author

cicheck

1 similar comment
@Cyber-SiKu
Copy link
Contributor Author

cicheck

@@ -323,16 +324,23 @@ int Warmup(fuse_ino_t key, const std::string& name, const std::string& value) {

std::vector<std::string> opTypePath;
curve::common::SplitString(value, "\n", &opTypePath);
if (opTypePath.size() != 3) {
if (opTypePath.size() != 4) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's better to give it a name rather than 4

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's better to give it a name rather than 4

fix

@@ -480,7 +482,7 @@ void WarmupManagerS3Impl::WarmUpAllObjs(
VLOG(9) << "no such warmup progress: " << key;
}
}
PutObjectToCache(context->key, context->buf, context->len);
PutObjectToCache(key, context->key, context->buf, context->len);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should L482 directly return?

And, since you have found corresponding progress in L478, can we reuse the results? So that, you don't have to search again in PutObjectToCache?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should L482 directly return?

And, since you have found corresponding progress in L478, can we reuse the results? So that, you don't have to search again in PutObjectToCache?

fix

WriteLockGuard lock(inode2ProgressMutex_);
auto ret = inode2Progress_.emplace(key, WarmupProgress());
auto ret = inode2Progress_.emplace(key, WarmupProgress(0, 0, type));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add another constructor for WarmupProgress that only accept type ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add another constructor for WarmupProgress that only accept type ?

fix

curvefs/src/client/warmup/warmup_manager.cpp Outdated Show resolved Hide resolved
@Cyber-SiKu
Copy link
Contributor Author

cicheck

5 similar comments
@Cyber-SiKu
Copy link
Contributor Author

cicheck

@Cyber-SiKu
Copy link
Contributor Author

cicheck

@Cyber-SiKu
Copy link
Contributor Author

cicheck

@Cyber-SiKu
Copy link
Contributor Author

cicheck

@Cyber-SiKu
Copy link
Contributor Author

cicheck

Signed-off-by: Cyber-SiKu <Cyber-SiKu@outlook.com>
@Cyber-SiKu
Copy link
Contributor Author

cicheck

2 similar comments
@Cyber-SiKu
Copy link
Contributor Author

cicheck

@Cyber-SiKu
Copy link
Contributor Author

cicheck


enum class WarmupStorageType {
kWarmupStorageTypeUnknown = 0,
kWarmupStorageTypeDisk = 1,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

local + mem cluster maybe clearer?

Comment on lines 288 to +295
int AddWarmupTask(curvefs::client::common::WarmupType type, fuse_ino_t key,
const std::string &path) {
const std::string &path,
curvefs::client::common::WarmupStorageType storageType) {
int ret = 0;
bool result = true;
switch (type) {
case curvefs::client::common::WarmupType::kWarmupTypeList:
result = g_ClientInstance->PutWarmFilelistTask(key);
result = g_ClientInstance->PutWarmFilelistTask(key, storageType);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not just treat it as a member variable of class?

@Cyber-SiKu Cyber-SiKu merged commit 6f63fdf into opencurve:master Apr 17, 2023
1 check passed
@Cyber-SiKu Cyber-SiKu deleted the feat/warmup_disk_memcached branch April 17, 2023 06:26
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

Successfully merging this pull request may close these issues.

None yet

3 participants