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

Clean up some of the files left after test runs #9539

Open
wants to merge 19 commits into
base: main
Choose a base branch
from

Conversation

mrambacher
Copy link
Contributor

This change attempts to clean up some of the test/temporary files left around after running the tests. This was discovered when attempting to run in a smaller (ram disk) TEST_TMPDIR.

Many test would destroy the DB on start but not on exit (DBTestBase does this). With this change, the DB directory is also deleted/destroyed on test completion.

This PR does not remove ALL of the files left after a test run but gets most of them. There are about 20-ish files/directories left around after this change (prior there were 65+ directories, some of them quite large).

Note that running tests via make check (and comparable commands) do not leave stuff around by explicitly deleting the TMPD directory after the command is complete. This is an issue when running tests by hand/individually (and possibly when running tests via ctest?)

@riversand963
Copy link
Contributor

riversand963 commented Feb 10, 2022

Thanks @mrambacher for the PR.
After running make check, I think we can locate the test tmp directory, say /dev/shm/rocksdb.ux_Lt/. Maybe the following command can tell us what files are still there:

find /dev/shm/rocksdb.ux_Lt/  -mindepth 1 -maxdepth 1 -not -empty -type d | awk '{split($0,a,"."); print(a[2]);} | awk '{split($0,b,"/"); print(b[2]);}'

Furthermore, it would be useful to use KEEP_DB env var to control whether the test files should be cleaned up or not, as in DBTestBase.

@mrambacher
Copy link
Contributor Author

Thanks @mrambacher for the PR. After running make check, I think we can locate the test tmp directory, say /dev/shm/rocksdb.ux_Lt/. Maybe the following command can tell us what files are still there:

find /dev/shm/rocksdb.ux_Lt/  -mindepth 1 -maxdepth 1 -not -empty -type d | awk '{split($0,a,"."); print(a[2]);} | awk '{split($0,b,"/"); print(b[2]);}'

At a certain point, I gave up trying to clean up the directories. Most of the stuff that is still around is because we do a DestroyDB rather than a DeleteDir and some part of the test created some file that Destroy does not touch. Some of these are things like "repair directories" or "backups" and I did not know if Destroy is broken in not removing them or something else.

Furthermore, it would be useful to use KEEP_DB env var to control whether the test files should be cleaned up or not, as in DBTestBase.

While I agree with you that it might be nice to do a KEEP_DB for this effort, there are a lot of caveats with that. First, the KEEP_DB only will work if you are running a single test and not a series of them (parallel tests run single tests). Each test will use the same database directory. What would be even better is if the test name was the database directory and we unified a test::Destroy methodology to delete what is in its directory (which could be a DestroyDB with a message if there is other stuff present).

@@ -1150,6 +1150,7 @@ TEST_F(DBBasicTest, DBClose) {
ASSERT_EQ(env->GetCloseCount(), 2);
options.info_log.reset();
ASSERT_EQ(env->GetCloseCount(), 3);
ASSERT_OK(DestroyDB(dbname, options));
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we use dbname_ in this test and let ~DBTestBase() take care of file deletion?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Theoretically it could but if you look at this test it has its own dbname and db member variable and does not use the corresponding class names or methods. I think the test should either be changed to use dbname_/db_ everywhere or left as-is at the moment. If you wish, I will add a "TODO" comment to get rid of the use of the local variables in favor of the class ones.

Copy link
Contributor

Choose a reason for hiding this comment

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

In the entire file db_basic_test.cc, I think only this test uses its own local dbname and db instead of dbname_ and db_. This indicates this test was not written properly. Given that the fix is simple, I would fix the test first instead of patching such a test.

Copy link
Contributor

Choose a reason for hiding this comment

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

While I understand the intention of minimizing the changes introduced by this PR, I think it's a case-by-case decision.
When making changes like this PR, if we encounter a (complex) bug or other issue which affects RocksDB library, it makes sense to address the issue in a separate PR and keep this PR simple. In this case,

  • it's all unit test code, and
  • Fix is simple and can potentially improve test code quality.

Therefore, I would suggest fixing it since it's a good opportunity.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In the entire file db_basic_test.cc, I think only this test uses its own local dbname and db instead of dbname_ and db_. This indicates this test was not written properly. Given that the fix is simple, I would fix the test first instead of patching such a test.

This test uses a custom env (TestEnv) that the others do not use. This makes it more problematic to get it so that the test can use dbname_ and the default destructor code.

@riversand963
Copy link
Contributor

KEEP_DB only will work if you are running a single test and not a series of them (parallel tests run single tests)

It's useful in the case of single test for the purpose of debugging.
If not set, the directory will be removed, which is what this PR wants to achieve.
I can see a clear benefit of checking KEEP_DB.

// Delete the external files
for (const auto& e : external) {
Status s = options.env->DeleteFile(e);
ASSERT_TRUE(s.IsNotFound() || s.ok());
Copy link
Contributor

Choose a reason for hiding this comment

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

When will s be non-ok?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If the file does not exist, the I presume s.IsNotFound would be returned. I do not know if that would ever happen or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants