iSALE関係のファイルを受け取りましたが、幾つかが消えました。 私はiSALE利用者なのでファイルiSALE-Dellen.zipを受け取り、それを展開して /mwork2 以下の私のディレクトリに置いていました。 すると、今朝になって多くのファイルが消えていることが分かりました。 これは何故でしょうか? これは、配布されたiSALE関係のファイルの最終アクセス日付が /mwork2 の定期ファイル削除 (atime +120) に抵触したからと予想されます。 配布されたファイル iSALE-Dellen.zip が以下であると仮定します。 m000% ls -l 合計 3292 -rw------- 1 root root 3367828 1月 17 09:38 iSALE-Dellen.zip このzipファイルを展開すると以下のようなファイルが現れるでしょう。 なお以下にある日付はファイルの最終アクセス日付 (atime) です。 m000% ls -lutrR iSALE-Dellen iSALE-Dellen: 合計 4140 -rw------- 1 root root 144194 7月 21 03:15 parameters.db -rw------- 1 root root 1926 7月 21 03:15 material.inp -rwx------ 1 root root 1504283 7月 21 03:15 iSALE2D -rw------- 1 root root 4610 7月 21 03:15 asteroid.inp -rw------- 1 root root 4940 7月 21 03:56 psp_setupPlots.py -rw------- 1 root root 756 7月 23 12:54 isale.pbs -rw------- 1 root root 48205 7月 23 19:10 pySALEPlot.pyc -rw------- 1 root root 67253 7月 23 19:10 pySALEPlot.py -rwx------ 1 root root 381143 7月 23 19:10 libpsp.so -rw------- 1 root root 1234 7月 23 19:15 R_TrP.py -rw------- 1 root root 1201 7月 23 19:16 tracer.py -rw------- 1 root root 1260 7月 23 19:17 profile.py -rw------- 1 root root 2655 7月 30 07:11 plot.py -rw------- 1 root root 2471 7月 30 07:13 DenTmp.py drwx------ 2 root root 4096 7月 30 07:15 eos iSALE-Dellen/eos: 合計 9068 -rw------- 1 root root 446667 7月 21 03:15 granit1.aneos -rw------- 1 root root 5544808 7月 21 03:56 h2o_ice.aneos -rw------- 1 root root 3748 7月 21 03:56 granitm.input -rw------- 1 root root 1172 7月 21 03:56 granite.tillo -rw------- 1 root root 3593 7月 21 03:56 granite.input -rw------- 1 root root 446704 7月 21 03:56 granit2.aneos -rw------- 1 root root 1284 7月 21 03:56 gabbro1.tillo -rw------- 1 root root 4009 7月 21 03:56 forstrm.input -rw------- 1 root root 3791 7月 21 03:56 fayaltm.input -rw------- 1 root root 3917 7月 21 03:56 dunite_.input -rw------- 1 root root 446681 7月 21 03:56 dunite_.aneos -rw------- 1 root root 2731 7月 21 03:56 calcite.input -rw------- 1 root root 446696 7月 21 03:56 calcite.aneos -rw------- 1 root root 3690 7月 21 03:56 basaltm.input -rw------- 1 root root 1050 7月 21 03:56 basalt_.tillo -rw------- 1 root root 441233 7月 21 03:56 basalt_.aneos -rw------- 1 root root 1114 7月 21 03:56 aluminu.tillo -rw------- 1 root root 1168 7月 21 03:56 wettuff.tillo -rw------- 1 root root 1088 7月 21 03:56 water__.tillo -rw------- 1 root root 446706 7月 21 03:56 water__.aneos -rw------- 1 root root 446729 7月 21 03:56 quarzit.aneos -rw------- 1 root root 5321 7月 21 03:56 quartzm.input -rw------- 1 root root 5216 7月 21 03:56 quartz_.input -rw------- 1 root root 1093 7月 21 03:56 pyrex__.tillo -rw------- 1 root root 1111 7月 21 03:56 polyeth.tillo -rw------- 1 root root 776 7月 21 03:56 perfgas.tillo -rw------- 1 root root 1002 7月 21 03:56 miesand.tillo -rw------- 1 root root 1175 7月 21 03:56 limesto.tillo -rw------- 1 root root 1109 7月 21 03:56 iron___.tillo -rw------- 1 root root 446656 7月 21 03:56 iron___.aneos -rw------- 1 root root 1357 7月 21 03:56 iceb___.tillo -rw------- 1 root root 1025 7月 21 03:56 ice____.tillo -rw------- 1 root root 3265 7月 21 03:56 ice____.input -rw------- 1 root root 1122 7月 21 03:56 fuseqtz.tillo -rw------- 1 root root 1170 7月 21 03:56 drytuff.tillo -rw------- 1 root root 785 7月 21 03:56 dry_air.tillo ご覧のように、各ファイルのatimeは現在より120日以上前のものです(上記の「7月」とは2018年7月のこと)。 この場合、上記ファイルを計算サーバの作業領域 /mwork{1,2}/ 以下に置いて使うと 毎日定時のファイル削除ルーチンに引っ掛かり、ファイルが削除されてしまいます。 これを避けるためには必要なファイルにアクセスしてatimeを更新するか、もしくは定期的に削除されないディレクトリにファイルを置いてください。 (最終更新日 2025年5年29日)
PBSスクリプトを実行してもジョブが投入されず、エラーメッセージも出ません。 どのようにすれば良いでしょうか? PBSスクリプトの書き間違えが考えられます。 例えば以下のようにオプション -N の引数に空白(スペース)が含まれるとジョブ投入は為されません (my と test の間)。 これはPBSの仕様です。 #PBS -N my test job.sh 詳しくは man pbs をご覧になり、qsubのオプション詳細をお調べください。 (最終更新日 2025年5月28日)
ジョブをqsubしたら以下のエラーが出てしまい、実行されません。 qsub: submit error (Bad UID for job execution MSG=User XXXXXX does not exist in server password file) これは計算ノードとサーバ側の通信が一時的に途切れたものと予想されます。 やや時間を置いてから再び qsub してみてください。 もし何度か試行しても状況が改善しなければ、問い合わせページからお問い合わせください。 (最終更新日 2025年5月28日)
解析サーバから作業領域 /mwork{1,2} を使うことは出来ますか? はい、出来ます。 たとえば an14 からは以下のように見えますので是非お使いください。 an14% df -m /mwork1 /mwork2/ Filesystem 1M-blocks Used Available Use% Mounted on mfs01.cfca.nao.ac.jp:/tank0/mwork 339354538 60790429 278564109 18% /misc/mwork1 mfs02.cfca.nao.ac.jp:/tank0/mwork 339347415 71606491 267740924 22% /misc/mwork2 an14% ls -lad /misc/mwork? lrwxrwxrwx. 1 root root 12 Mar 18 19:43 /mwork1 -> /misc/mwork1/ lrwxrwxrwx. 1 root root 12 Mar 18 19:43 /mwork2 -> /misc/mwork2/ (最終更新日 2025年5月28日)
quotaコマンドを使っても/mwork{1,2}について情報が現れません。 どのようにすれば情報を得られるでしょうか? /mwork{1,2}を提供するnfsサーバ (FreeBSD) は m000 (Rocky Lonux) とOSが異なるため、現時点ではquota状況を即時に表示するコマンドが未だありません。 代替として全利用者のquota状況を記したファイル/mwork{1,2}/userspace.txtが準備されており、 これらは60分に1度の頻度で更新されています。このファイルをcatするか、以下のようにしてください。 grep `whoami` /mwork{1,2}/userspace.txt すると以下の例のようにご自分の利用状況(右から二欄目の数値)およびquota上限値(右端欄の数値)が表示されます。 /mwork1/userspace.txt:POSIX User itootk 10.1T 24T /mwork2/userspace.txt:POSIX User itootk 224G 24T (最終更新日 2025年5月28日)
/mwork2 に書き込もうとしたら「ディスク使用量制限を超過しました.」と言われました。 以下のような表示が出ます。 % echo something > /mwork2/username/output.txt /mwork2/username/output.txt: ディスク使用量制限を超過しました. 何が起こっており、私はどう対処すれば良いでしょうか? これはディレクトリ /mwork2 が有するquota制限に抵触したためです。 試しに環境変数 LANG を C へ変更すると、より直截なメッセージが出ます。 % env LANG=C echo something > /mwork2/username/output.txt /mwork2/username/output.txt: Disk quota exceeded. 不要なファイルを削除または移動してください。 また、この下にあるQ&A「quotaコマンドを使っても /mwork{1,2} について情報が現れません」も併わせてお読みください。 (最終更新日 2025年5月28日)
作業用ディレクトリ /mwork{1,2} に quota 制限は掛かっていますか? はい、掛かっています。 利用の手引きを御覧ください。 但し、この領域でquotaの溢れが発生しても利用者には電子メールなどでの警告は届きません。 ご自分がどのくらいのファイル量を保持しているかには常に留意してください。 (最終更新日 2025年5月28日)
/mwork{1,2} は以前あった作業領域に比べてだいぶ速いようです。何が違うのですか? その通りです。 特に小さなファイルを多数書き込む場合、/mwork{1,2} への書き込み速度は以前にあった作業領域へのそれよりずっと高いです。 これは /mwork{1,2} がFreeBSDのZFSファイルシステムにssdによるキャッシュ機能を与えたものだからです。 とりわけ小さなファイルを多く書き込む利用者は、その高い速度を体感するでしょう。 (最終更新日 2024年以前)
計算サーバ上でPython 3系は使えますか? はい、使えます。module コマンドを使ってください。 module load miniconda/3 なお pySALEPlot は Python 2 系にしか対応していません。 使い分けを工夫してください。 (最終更新日 2024年以前)