僕の備忘録(PC、UN*X、ネットワーク関連が中心)なんです。
自分の書いたところは適当(な時とか)に書き換えますので御了承を。
同じ量でも多数のファイル転送は時間がかかる。
1Mのファイルひとつは瞬速でコピーできても、
32バイトが32768個あると...
/dev/urandomから読みだしたファイルの山を、
sshfsでマウントしたポイントにcp -aしてみる。
イーサネットは一応GB。
$ ls 128 1k 1m.img 256 32 512 64 $ time cp 1m.img $HOME/remote/ real 0m0.024s user 0m0.000s sys 0m0.004s $ time cp -a 1k $HOME/remote/ real 0m4.802s user 0m0.048s sys 0m0.164s $ time cp -a 512 $HOME/remote/ real 0m9.704s user 0m0.064s sys 0m0.372s $ time cp -a 256 $HOME/remote/ real 0m19.380s user 0m0.172s sys 0m0.724s $ time cp -a 128 $HOME/remote/ real 0m38.442s user 0m0.272s sys 0m1.368s $ time cp -a 64 $HOME/remote/ real 1m16.699s user 0m0.472s sys 0m2.744s $ time cp -a 32 $HOME/remote/ real 2m34.144s user 0m0.912s sys 0m5.560s
ほぼファイルの「数」に比例しているようだ。
スイッチを100Mに変えてみた。
変化については1Gと同様。
「ちょっと遅くなった」くらいしか違わないようだ。
$ time cp 1m.img $HOME/remote/ real 0m0.099s user 0m0.000s sys 0m0.000s $ time cp -a 1k $HOME/remote/ real 0m5.796s user 0m0.036s sys 0m0.176s $ time cp -a 512 $HOME/remote/ real 0m11.257s user 0m0.080s sys 0m0.320s $ time cp -a 256 $HOME/remote/ real 0m22.118s user 0m0.152s sys 0m0.680s $ time cp -a 128 $HOME/remote/ real 0m43.997s user 0m0.292s sys 0m1.384s $ time cp -a 64 $HOME/remote/ real 1m27.289s user 0m0.528s sys 0m2.724s $ time cp -a 32 $HOME/remote/ real 2m55.206s user 0m1.124s sys 0m5.440s
どれくらいのディスクスペースを占めているかも。
$ ls 128 1k 1m.img 256 32 512 64 $ for node in `ls`; do du $node; done | sort -n 1024 1m.img 4124 1k 8244 512 16484 256 32960 128 65964 64 131952 32
特定の物理ボリューム上にあるデータを 違う物理ボリュームに移動。もちろん アンマウントもせずにデータ保持で。
まず初期状態。
$ sudo pvs PV VG Fmt Attr PSize PFree /dev/sdb1 lvm2 --- 3.00g 3.00g /dev/sdb2 lvm2 --- 2.59g 2.59g
ボリュームグループを作成し、小さい方の 物理ボリュームを加え、 その全部を論理ボリュームにする。
$ sudo vgcreate tvs /dev/sdb2 Volume group "tvs" successfully created $ sudo lvcreate -l 100%FREE tvs -n narrow Logical volume "narrow" created.
パーティション作成にマウント。
$ sudo mkfs -t ext4 /dev/tvs/narrow
mke2fs 1.43.3 (04-Sep-2016)
Discarding device blocks: done
Creating filesystem with 677888 4k blocks and 169680 inodes
Filesystem UUID: ac47ff77-8792-4ea6-ad23-bd8a1a3d3092
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
$ sudo mount /dev/tvs/narrow /media/temp
適当なデータも置いておく。
media/temp$ sudo dd if=/dev/urandom of=100m.img bs=1M count=100 100+0 レコード入力 100+0 レコード出力 104857600 bytes (105 MB, 100 MiB) copied, 5.68974 s, 18.4 MB/s media/temp$ df -h | sed -n '1p;$p' ファイルシス サイズ 使用 残り 使用% マウント位置 /dev/mapper/tvs-narrow 2.5G 108M 2.3G 5% /media/temp
大きい方の物理ボリューム追加。
$ sudo vgextend tvs /dev/sdb1 Volume group "tvs" successfully extended $ sudo pvs PV VG Fmt Attr PSize PFree /dev/sdb1 tvs lvm2 a-- 3.00g 3.00g /dev/sdb2 tvs lvm2 a-- 2.59g 0 $ sudo vgs VG #PV #LV #SN Attr VSize VFree tvs 2 1 0 wz--n- 5.58g 3.00g
で、始めの小さい方の物理ボリュームから
データを大きい方に移動させる。
この場合、ファイルシステムのデータの
多寡は関係なさげ(物理ボリューム
全体を移す模様)
$ sudo pvmove /dev/sdb2 /dev/sdb1 /dev/sdb2: Moved: 0.15% /dev/sdb2: Moved: 25.23% /dev/sdb2: Moved: 45.17% /dev/sdb2: Moved: 69.64% /dev/sdb2: Moved: 99.55% /dev/sdb2: Moved: 100.00%
で、その結果。
$ sudo pvs PV VG Fmt Attr PSize PFree /dev/sdb1 tvs lvm2 a-- 3.00g 420.00m /dev/sdb2 tvs lvm2 a-- 2.59g 2.59g $ df -h | sed -n '1p;$p' ファイルシス サイズ 使用 残り 使用% マウント位置 /dev/mapper/tvs-narrow 2.5G 108M 2.3G 5% /media/temp
もちろんこの後、/dev/sdb2を引き抜いても構わないと。
$ sudo vgreduce tvs /dev/sdb2 Removed "/dev/sdb2" from volume group "tvs" $ sudo pvs PV VG Fmt Attr PSize PFree /dev/sdb1 tvs lvm2 a-- 3.00g 420.00m /dev/sdb2 lvm2 --- 2.59g 2.59g $ ls /media/temp/ 100m.img lost+found
パーティションのサイズを変えないので、
移動元と移動先のサイズには注意が要りそうだ。
論理ボリュームがどちらにも収まるサイズであれば
いいのだろうけど。
リンクはご自由にどうぞ。でもURLや内容が変った場合はあしからず。