/glv1 で過去に生成されたメタデータの不整合に起因すると見られる障害が頻発しており，
完全な修復を行うことが困難なため /glv1 ユーザの皆様にファイルの移動をお願いしております．
Last Updated: 2024/07/04
ディレクトリ構成
大元の /glv1 のデータは7つのディレクトリに分散して保存されており，それらをまとめて /glv1 として表示していました．
現在，データ保護のため読み込みのみ（書き込み不可）でマウントしている影響でまとめることができず，各々のディレクトリは解析サーバに以下のように個別にマウントされています．
$ df /glv1/brick* -Th
ファイルシス タイプ サイズ 使用 残り 使用% マウント位置
glfs103:/mnt/brick10 nfs 242T 93T 150T 39% /glv1/brick10
glfs103:/mnt/brick11 nfs 242T 130T 113T 54% /glv1/brick11
glfs103:/mnt/brick12 nfs 242T 186T 57T 77% /glv1/brick12
glfs103:/mnt/brick13 nfs 242T 189T 54T 78% /glv1/brick13
glfs103:/mnt/brick20 nfs 242T 186T 57T 77% /glv1/brick20
glfs103:/mnt/brick21 nfs 242T 186T 57T 77% /glv1/brick21
glfs103:/mnt/brick22 nfs 242T 96T 147T 40% /glv1/brick22
700 個ファイルがあれば，おおむね100個ずつが異なるファイルシステムにランダムに保存されているとお考えください．
データの実体の位置確認と移動
仮にユーザ cfcauserが /glv1/cfcauser/hoge/piyo.shというファイルを保持していた場合，
7つのディレクトリのうちのどこかにファイルが保管されています．以下のようにしてその場所を確認できます．
[aterui@an09 ~]$ /home/scripts/lsg.sh /glv1/cfcauser/hoge/ -l | grep -e ^Dir -e piyo.sh
DirectoryPath /glv1/brick10/glv1/cfcauser/hoge/ -l
DirectoryPath /glv1/brick11/glv1/cfcauser/hoge/ -l
DirectoryPath /glv1/brick12/glv1/cfcauser/hoge/ -l
---------T 2 cfcauser user 0 2月 11 17:20 piyo.sh~
DirectoryPath /glv1/brick13/glv1/cfcauser/hoge/ -l
DirectoryPath /glv1/brick20/glv1/cfcauser/hoge/ -l
-rwxrwxr-- 2 cfcauser user 2518 2月 21 14:10 piyo.sh
-rwxrwxr-- 2 cfcauser user 2527 2月 9 16:32 piyo.sh~
DirectoryPath /glv1/brick21/glv1/cfcauser/hoge/ -l
DirectoryPath /glv1/brick22/glv1/cfcauser/hoge/ -l
ここで/home/scripts/lsg.shは brick10からbrick22 を横断して ls を行うシェルスクリプトです．適宜ご利用ください．
この例の場合，
/glv1/brick20/glv1/cfcauser/hoge/
にある piyo.sh がファイルの実体で，brick12 に存在している
---------T 2 cfcauser user 0 2月 11 17:20 piyo.sh~
は，リネーム等で保存場所が変わった時に生成されたファイルです．したがって,
$ cp /glv1/brick20/glv1/cfcauser/hoge/piyo.sh /fs52/cfcauser/hoge/
のように実体のみを移行先のディレクトリに複製してください．
tab 補完が行えないのが不便なので lsg2.sh というスクリプトも用意しました．
lsg2.sh /glv1/brick10/glv1/
のようにすると tab 補完しつつ横断検索が可能です．
ディレクトリの統合
ディレクトリを統合しつつ新領域に複製したい場合，たとえば
/glv1/brick[10,11,12,13,20,21,22]/glv1/username/hoge/piyo
を
./merge/hoge/piyo
に纏めようとする場合，最も単純なのは以下の cp による方法です．
$ mkdir -p merge/hoge
$ cp -r /glv1/brick10/glv1/username/hoge/piyo ./merge/hoge/
$ cp -r /glv1/brick11/glv1/username/hoge/piyo ./merge/hoge/
:
:
$ cp -r /glv1/brick22/glv1/username/hoge/piyo ./merge/hoge/
と繰り返すと各 brick の piyo 以下が ./merge/hoge/piyo に統合されます．
失敗例として cp コマンドの発行時にコピー先を
./merge/hoge/piyo
にしても良いように感じますが，この場合
./merge/hoge/piyo/piyo
を作成しようとして失敗します．
cp のかわりに rsync を使用しても構いません．同様の結果を得るには以下のようになるでしょう．
$ mkdir -p merge/hoge
$ rsync -aq brick10/glv1/hoge/ merge/hoge/
$ rsync -aq brick11/glv1/hoge/ merge/hoge/
:
:
$ rsync -aq brick22/glv1/hoge/ merge/hoge/
brickの数字を書き換えて 7回実行するのは面倒なので，lsg.sh と同じようにスクリプト化してしまうのが良いでしょう．
#!/bin/bash --norc
readonly BRICK=("brick10" "brick11" "brick12" "brick13" "brick20" "brick21" "brick22")
for TARGET in ${BRICK[@]}; do
mark=${TARGET:0:1}
echo $mark
if [ "$mark" == '#' ]; then
continue
fi
rsync -a --quiet ${TARGET}/glv1/hoge/ merge/hoge/
done
/home/scripts/merge.sh
として解析サーバに置いてあります． rsync の行を適宜書き換えてお試しください．
ネットワーク越しの転送が無いため z オプションはおそらく効果が無いか悪影響があります．
rsync の場合中断からの再開や --dry-run など各種の制御が容易ですが，
rsync は複製の開始前にファイルのリストを作成するため，ディレクトリ内のファイル数が多い（数百万ファイル）場合には
動作が不安定になる，または失敗する可能性があります．
その場合の自動化については個別にご相談下さい．