|
| 1 | + |
| 2 | +This document outlines the procedures conducted to test the zstash bloclking |
| 3 | +and non-blocking behavior. |
| 4 | + |
| 5 | +Note: As it was intended to test blocking with regard to archive tar-creations |
| 6 | +vs Globus transfers, it wsa convenient to have both source snd destination be |
| 7 | +the same Globus endpoint. Effectively, we are employing Globus merely to move |
| 8 | +tar archive files from one directory to another on the same file system. |
| 9 | + |
| 10 | +The core intent in implementing zstash blocking is to address a potential |
| 11 | +"low-disk" condition, where tar-files created to archive source files could |
| 12 | +add substantially to the disk load. To avoid disk exhaustion, "blocking" |
| 13 | +("--non-blocking" is absent on the command line), tar-file creation will |
| 14 | +pause to wait for the previous tarfile globus transfer to complete, so that |
| 15 | +the local copy can be deleted before the next tar-file is created. |
| 16 | + |
| 17 | +I. File System Setup |
| 18 | +==================== |
| 19 | + |
| 20 | +s one may want, or need to re-conduct testing under varied conditions, the |
| 21 | +test script: |
| 22 | + |
| 23 | + test_zstash_blocking.sh |
| 24 | + |
| 25 | +will establish the following directory structure in the operator's current |
| 26 | +working directory: |
| 27 | + |
| 28 | + [CWD]/src_data/ |
| 29 | + |
| 30 | + - contains files to be tar-archived. One can experiment |
| 31 | + with different sizes of files to trigger behaviors. |
| 32 | + |
| 33 | + [CWD]/src_data/zstash/ |
| 34 | + |
| 35 | + - default location of tarfiles produced. This directory is |
| 36 | + created automatically by zstash unless "--cache" indicates |
| 37 | + an alternate location. |
| 38 | + |
| 39 | + [CWD]/dst_data/ |
| 40 | + |
| 41 | + - destination for Globus transfer of archives. |
| 42 | + |
| 43 | + [CWD]/tmp_cache/ |
| 44 | + |
| 45 | + - [Optional] alternative location for tar-file generation. |
| 46 | + |
| 47 | +Note: It may be convenient to create a "hold" directory to store files of |
| 48 | +various sizes that can be easily produced by running the supplied scripts. |
| 49 | + |
| 50 | + gen_data.sh |
| 51 | + gen_data_runner.sh |
| 52 | + |
| 53 | +The files to be used for a given test must be moved or copied to the src_data |
| 54 | +directory before a test is initiated. |
| 55 | + |
| 56 | +Note: It never hurts to run the supplied script: |
| 57 | + |
| 58 | + reset_test.sh |
| 59 | + |
| 60 | +before a test run. This will delete any archives in the src_data/zstash |
| 61 | +cache and the receiving dst_data directories, and delete the src_data/zstash |
| 62 | +directory itself if it exists. This ensures a clean restart for testing. |
| 63 | +The rad data files placed into src_data are not affected. |
| 64 | + |
| 65 | +II. Running the Test Script |
| 66 | +=========================== |
| 67 | + |
| 68 | +The test script "test_zstash_blocking.sh" accepts two positional parameters: |
| 69 | + |
| 70 | + test_zstash_blocking.sh (BLOCKING|NON_BLOCKING) [NEW_CREDS] |
| 71 | + |
| 72 | +On an initial run, or whenever Globus complains of authentication failures, |
| 73 | +add "NEW_CREDS" as the second parameter. This will act to delete your |
| 74 | +cached Globus credentials and trigger prompts for you to paste login URLs |
| 75 | +to your browser (generally one per endpoint) which requires that you conduct |
| 76 | +a login sequence, and then paste a returned key-value at the bash command |
| 77 | +prompt. After both keys are accepted, you can re-run the test script |
| 78 | +without "NEW_CREDS", until the credentials expire (usually 24 hours.) |
| 79 | + |
| 80 | +If "BLOCKING" is selected, zstash will run in default mode, waiting for |
| 81 | +each tar file to complete transfer before generating another tar file. |
| 82 | + |
| 83 | +If "NON_BLOCKING" is selected, the zstash flag "--non-blocking" is supplied |
| 84 | +to the zstash command line, and tar files continue to be created in parallel |
| 85 | +to running Globus transfers. |
| 86 | + |
| 87 | +It is suggested that you reun the test script with |
| 88 | + |
| 89 | + test_zstash_blocking.sh (BLOCKING|NON_BLOCKING) > your_logfile 2>&1 |
| 90 | + |
| 91 | +so that your command prompt returns and you can monitor progress with |
| 92 | + |
| 93 | + snapshot.sh |
| 94 | + |
| 95 | +which will provide a view of both the tarfile cache and the destination |
| 96 | +directory for delivred tar files. It is also suugested that you name your |
| 97 | +logfile to reflect the date, and whether BLOCKING or not. |
| 98 | + |
| 99 | + |
| 100 | +FINAL NOTE: In the zstash code, the tar file "MINSIZE" parameter is taken |
| 101 | +to be (int) multiples of 1 GB. During testing, this had been changed to |
| 102 | +"multiple of 100K" for rapid testing. It may be useful to expose this as |
| 103 | +a command line parameter for debugging purposes. |
0 commit comments