slop_space_test from longevity runfile is missing

[sdimitro]

This test was introduced in illumos with the zpool checkpoint feature.

When the commit was ported to ZoL (https://github.com/zfsonlinux/zfs/commit/d2734cce68cf740e015312314415f9034c67851c) the runfile of the test was introduced but the actual test is missing.

[bunder2015]

had a quick glance at the source in the openzfs repo, it looks like it should work with a couple small changes (module parameter changes via mdb, possibly dd syntax)

edit: dd ostride= might be a problem, linux doesn't seem to have an equivalent.

[ahrens]

stride_dd (included in the test suite) can be used instead of dd ostride=

[bunder2015]

hi, do you have a link for that? I couldn't seem to find it. thanks

[ahrens]

My apologies, I didn't realize it isn't upstream yet, it's part of https://github.com/zfsonlinux/zfs/pull/7958. Probably easiest to wait for that to land.

[stale[bot]]

This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.

[behlendorf]

Everything needed to add this test case should now be available. It'd be great to see it added.

[Adi-Goll]

@behlendorf @amotin I took some time to test out the code linked here. I ran this test and it appears to timeout on the command log_mustnot dd if=/dev/zero of=$FS1FILE bs=512. I'm unsure what the expected behavior is here. We are running this command to hit the first slop space limit (128M), but even after adjusting the timeout to 30 minutes, and writing 217GB which clearly surpasses 128M, there is no indication of a space issue.

I would think the expected behavior is returning ENOSPC when we write to a pool and have hit the slop space limit. However, this command just keeps writing zeros into the output file. If anyone has any thoughts on how to proceed that would be awesome!

For reference, here is the commit with the test file added: https://github.com/Adi-Goll/zfs/commit/41c3885eb3d27f5b1ef860250b0259b3946cb03b

[amotin]

@Adi-Goll I haven't looked into that test much, but what I see there is zero writes with compression enabled. With compression enabled you can write zeroes till the heat death of the universe. I guess this test might be broken from the day when compression become enabled by default.