https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-8940 Lustre <p>In sanity-hsm df is used to check if there is enough space on the file system before creating a rather large file (with make_custom_file_for_progress()). If there is not enough space, a call to cleanup_large_files() is issued and then df is used once again to check that there is now enough space.</p> <p>The thing is, df takes time to see the update in free space, more than du for example (even with the option --sync).<br/> To reproduce:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>dd if=/dev/zero of=/mnt/lustre/file count=100 bs=1M df -h find /mnt/lustre -size +10M -delete &amp;&amp; df -h [--sync ] &amp;&amp; du -s /mnt/lustre # Wait around 3 to 5 seconds df -h </pre> </div></div> <p>You can check the output of the first two df commands, the "Used" column should be the same. But du immediatly reflects the actual size.</p> LU-8940

tests: df is not responsive enough

Bug Minor Closed Fixed John Hammond CEA Thu, 15 Dec 2016 14:10:10 +0000 Tue, 29 Mar 2022 20:10:46 +0000 Tue, 29 Mar 2022 20:10:45 +0000 0 4 <p>Would it be satisfying enough to use "du" instead ?</p> <p>Quentin, could you clarify is the problem that the test should be calling cleanup_large_files() but it isn't? Or something else? Is it causing a spurious test failure? If so the could you post the logs?</p> <p>cleanup_large_files() is called, at the right times, but we check how much space it frees too quickly after and end up thinking there is not enough space when there is. The consequence is that some tests are skipped with the message "not enough space" when they should not.</p> <p>Overall this is not too problematic, but it would still be nice to fix.</p> <p>Quentin, could you try add a call to wait_destroy_complete after find and see if works?</p> <p>The timeout of wait_complete_destroy is 5 seconds. When I run my test it sometimes is enough, sometimes it is not. I think it would be better to use a non-sleeping and more deterministic method.</p> <p>A workaround in sanity-hsm.sh is not to use make_custom_file_for_progress() and use empty file as much as possible (or very small files).</p> <p>In general we should not use empty files in sanity-hsm. Since this will silently reduce the code coverage in many places. (BTW we should also avoid using copies of /etc/</p> {hosts,passwd,...} <p> as a small file, since these may be empty on some distros. It's better to use dd if=/dev/urandom ... to create the small files.)</p> <p>I am not sure I agree with that. Using not empty files pretty much only tests how the copytool behaves and very little tests are "copytool oriented".</p> <p>The main problem related to using big files is that the copytool's bandwidth is artificially capped at 1MB/s. This unnecessarily slows down many tests in sanity-hsm. Overall I am not asking for complete removal of big files, I am just asking for each use to be documented and rationalized (which is what motivates lu-8950).</p> <p>Anyway, using small or empty files is just a workaround. We still have to find a solution. I personnaly think that it is ok for df to report outdated information as long as the "--sync" option forces an update.</p> <p>We were actually pretty close to finding a general fix to this, we tried <tt>wait_destroy_complete()</tt> and it would seem <tt>wait_delete_complete()</tt> was what we needed (credit to Andreas Dilger).</p> <p>Fixed by <a href="https://jira.whamcloud.com/browse/LU-8950" title="tests: sanity-hsm: use make_custom_file_for_progress() as little as possible" class="issue-link" data-issue-key="LU-8950"><del>LU-8950</del></a> tests: standardize file creation in sanity-hsm.</p> Related LU-8950 Development Rank 1|hzyyhr: Rank (Obsolete) 9223372036854775807 Severity