Project

General

Profile

Actions

action #117211

closed

coordination #121876: [epic] Handle openQA review failures in Yam squad - SLE 15 SP5

Add sync after dd in snapper_cleanup_timeline

Added by rainerkoenig about 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
High
Assignee:
Target version:
Start date:
2022-09-26
Due date:
% Done:

0%

Estimated time:

Description

Motivation

The snapper_cleanup_timeline test fails with the message that the free disk space is more than 20%.

The root cause of this problem, is that the test module first performs a dd command and immediately after that it does a df -h to determine the used disk space. The problem is, that dd is using kernel buffers that will then transfered to disk after dd is finished. If df -h is performed immediately after dd then we are still in the phase of transfering buffers to the disk and therefore we get a lower disk usage.

The solution for this is calling sync after the dd command which ensures that all bufffers are indeed written to disk. I made a PoC that looks like this:

    assert_script_run("dd if=/dev/urandom of=/tmp/blob bs=10M count=$block_number", timeout => 1500,
        fail_message => "Failed to fill up disk space");
    assert_script_run("sync", timeout => 60, fail_message => "Failed to sync");
    $used_disk = convert2numeric(get_used_partition_space("/"));

To fix this the Units that are returned from df -h in the filesystem_utils package need to be evaluated as well, otherwise we compare Megabytes with Gigabytes which is obviously wrong. However you do this, keep an eye on where the values are used, because this might affect the $block_number variable used in the dd command.

Acceptance criteria

AC1: The sync is implemented after the dd command and the correct amount of used space is reported.

Additional information

status=progress option might help because it doesn't return until finished, instead of sync command.


Related issues 1 (1 open0 closed)

Related to qe-yam - action #117511: Take into account units when using library filesystem_utils in snapper_cleanup_timelineNew2022-10-04

Actions
Actions #1

Updated by JERiveraMoya about 2 years ago

  • Tags set to qe-yast-refinement
  • Subject changed from Fix problems in snapper_cleanup_timeline.pm to Add syn after dd in snapper_cleanup_timeline
  • Description updated (diff)
  • Target version set to Current
Actions #2

Updated by JERiveraMoya about 2 years ago

  • Related to action #117511: Take into account units when using library filesystem_utils in snapper_cleanup_timeline added
Actions #3

Updated by JERiveraMoya about 2 years ago

  • Priority changed from Normal to High
Actions #4

Updated by rainerkoenig about 2 years ago

  • Subject changed from Add syn after dd in snapper_cleanup_timeline to Add sync after dd in snapper_cleanup_timeline
Actions #5

Updated by coolgw about 2 years ago

checked

Actions #6

Updated by JERiveraMoya about 2 years ago

  • Tags deleted (qe-yast-refinement)
  • Description updated (diff)
  • Status changed from New to Workable
Actions #7

Updated by coolgw about 2 years ago

  • Assignee set to coolgw
Actions #8

Updated by coolgw about 2 years ago

  • Status changed from Workable to In Progress
Actions #10

Updated by JERiveraMoya about 2 years ago

  • Status changed from In Progress to Resolved
Actions #11

Updated by openqa_review about 2 years ago

  • Status changed from Resolved to Feedback

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: snapper_cleanup_timeline
https://openqa.suse.de/tests/9970176#step/snapper_cleanup_timeline/1

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
  3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.

Actions #12

Updated by rainerkoenig about 2 years ago

  • Status changed from Feedback to In Progress
Actions #13

Updated by rainerkoenig about 2 years ago

Back to "in Progress". Seems like the parameter status=progress for dd does not solve the problem.

The dd man page says:

       status=LEVEL
              The LEVEL of information to print to stderr; 'none'
              suppresses everything but error messages, 'noxfer'
              suppresses the final transfer statistics, 'progress' shows
              periodic transfer statistics

This makes me doubt if this parameter really enforces the writing of buffers.

Actions #15

Updated by JERiveraMoya about 2 years ago

  • Status changed from In Progress to Resolved
Actions #16

Updated by JERiveraMoya almost 2 years ago

  • Parent task set to #121876
Actions

Also available in: Atom PDF