Skip to content

Conversation

@jainakanksha-msft
Copy link
Collaborator

No description provided.

Readonly: true,
State: dcache.StateReady,
Epoch: 1,
Epoch: 0,
Copy link
Collaborator

Choose a reason for hiding this comment

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

why do you change this?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is needed to start with version 1.
Right now, we don't use version 1

Comment on lines 77 to 78
RVMap map[string]RawVolume `json:"rv-list"`
MVMap map[string]MirroredVolume `json:"mv-list"`
Copy link
Collaborator

@linuxsmiths linuxsmiths Jun 19, 2025

Choose a reason for hiding this comment

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

and this?
it's a map and not a list, so let it be called map

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I made it consistent throughout.
fs=debug consider it as rv-list mv-list, which makes the things inconsistent. While reading data in automation script.

Comment on lines 25 to 30
# Check if number of nodes is provided
if [ $# -ne 1 ]; then
echo "Usage: $0 <number_of_nodes>"
echo "Example: $0 5"
exit 1
fi
Copy link
Collaborator

Choose a reason for hiding this comment

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

why do we need to take number of nodes from user?
why can't we deduce it from clustermap.
I'd not want to take any additional info from the user. He should be able to point the test script at a cluster and it should be able to test it by gathering the reqd infro from the clustermap.

local next_epoch=$(expr $LAST_UPDATED_AT + $CLUSTERMAP_EPOCH)
local now=$(date +%s)
local secs_to_next_epoch=$(expr $next_epoch - $now + 2)
local secs_to_next_epoch=$(expr $next_epoch - $now + 5)
Copy link
Collaborator

Choose a reason for hiding this comment

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

why did you have to change this?
did it fail and if so did you analyze why 2 sec buffer was not sufficient.

Comment on lines +224 to +231
# Check if we're close to the heartbeat timeout boundary
local heartbeat_timeout=$(expr $HB_SECONDS \* $HB_TILL_NODE_DOWN - 2)
local secs_to_next_epoch_with_buffer

if [ $secs_to_next_epoch -lt $heartbeat_timeout ]; then
# Add an additional epoch period if we're close to timeout
secs_to_next_epoch_with_buffer=$(expr $secs_to_next_epoch + $CLUSTERMAP_EPOCH + 5)
echo "Close to heartbeat timeout boundary, adding extra epoch wait time"
Copy link
Collaborator

@linuxsmiths linuxsmiths Jun 19, 2025

Choose a reason for hiding this comment

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

general comment.
pl;s indent uniformly across the file, use 4 spaces

local file_name=$2
local block_size=$3
local count=$4
ssh $vm "dd if=/dev/urandom of=$MOUNTDIR/fs=dcache/$file_name bs=$block_size count=$count"
Copy link
Collaborator

Choose a reason for hiding this comment

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

add conv=fsync to be safe
to all dds

Comment on lines +332 to +333
local block_size=$3
local count=$4
Copy link
Collaborator

Choose a reason for hiding this comment

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

just take size_in_GB as param and deduce these two internally

ssh $vm "dd if=/dev/urandom of=$MOUNTDIR/fs=azure/$file_name bs=$block_size count=$count"
}

write_data_in_mountdir()
Copy link
Collaborator

@linuxsmiths linuxsmiths Jun 19, 2025

Choose a reason for hiding this comment

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

call it write_data_on_both()
, since that's what is the intent..
for others too use on in place of in

@jainakanksha-msft jainakanksha-msft added this to the v2-2.6.0 milestone Jul 22, 2025
@linuxsmiths linuxsmiths force-pushed the feature/dcache branch 2 times, most recently from 9d56910 to 43a8bfc Compare October 3, 2025 00:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants