ここでちょっと脱線。下記のサイトの記述が気になった。
https://blog.pfs.nifcloud.com/174/
上記サイト曰はく、
「ところが、LVMスナップショット方式も万能ではありません。
この方式の最大の弱点は、スナップショットを取得している間、元のファイルシステムに対する書き込み性能がガタ落ちになってしまう」
上記を確かめる。
【お題】
レガシースナップショットの有無でソースボリュームのシーケンシャルwrite時間にどのくらいの差があるか調べる。
方法は、ソースボリュームのファイルシステム(マウントポイント/src)下記のファイル
# ls -lh /src/1/usr/local/src/oracle-database-ee-18c-1.0-1.x86_64.rpm
-rw-r--r--. 1 root root 3.4G 9月 7 10:36 /src/1/usr/local/src/oracle-database-ee-18c-1.0-1.x86_64.rpm
を同階層に名前を変えてコピーした際の所要時間を測る。(sequential read+write)
ついでに、catして標準出力を/dev/nullにした際の所要時間も測る。(sequential read)
順序はなぜか下記のとおりw
X-3.レガシースナップショットが2個だけ有るソースボリュームのシーケンシャルwrite時間
# lvcreate --size 10G -s -n legacy_snap2 /dev/src/testlv
----(略)----
# lvs | grep testlv
testlv_bk dst -wi-a----- 30.00g
legacy_snap src swi-aos--- 10.00g testlv 0.46
legacy_snap2 src swi-a-s--- 10.00g testlv 0.00
testlv src owi-aos--- 200.00g
上記のように、testlvリニアボリュームに対するレガシースナップショットボリュームlegacy_snapが２個ある状態をつくる。
# pwd
/src/1/usr/local/src# rm -f hoge
# echo 3 > /proc/sys/vm/drop_caches
# time cp oracle-database-ee-18c-1.0-1.x86_64.rpm hoge
real 3m22.176s
user 0m0.037s
sys 0m7.886s
# time cat oracle-database-ee-18c-1.0-1.x86_64.rpm > /dev/null
real 0m33.554s
user 0m0.015s
sys 0m4.074s
X-2.レガシースナップショットが1個だけ有るソースボリュームのシーケンシャルwrite時間
# lvremove src/legacy_snap2
Do you really want to remove active logical volume src/legacy_snap2? [y/n]: y
Logical volume "legacy_snap2" successfully removed
# lvs | grep testlv
testlv_bk dst -wi-a----- 30.00g
legacy_snap src swi-aos--- 10.00g testlv 33.99
testlv src owi-aos--- 200.00g
上記のように、testlvリニアボリュームに対するレガシースナップショットボリュームlegacy_snapが１個ある状態をつくる。
# pwd
/src/1/usr/local/src# rm -f hoge
# rm -f hoge
# echo 3 > /proc/sys/vm/drop_caches
# time cp oracle-database-ee-18c-1.0-1.x86_64.rpm hoge
real 0m37.372s
user 0m0.026s
sys 0m6.490s
# echo 3 > /proc/sys/vm/drop_caches
# time cat oracle-database-ee-18c-1.0-1.x86_64.rpm > /dev/null
real 0m31.772s
user 0m0.023s
sys 0m4.504s
もう一回！
# rm -f hoge
# echo 3 > /proc/sys/vm/drop_caches
# time cp oracle-database-ee-18c-1.0-1.x86_64.rpm hoge
real 0m37.571s
user 0m0.027s
sys 0m6.371s
X-1.スナップショットが無いソースボリュームのシーケンシャルwrite時間
# mount | grep snap
/dev/mapper/src-legacy_snap on /legacy_snap type xfs (rw,relatime,seclabel,nouuid,attr2,inode64,noquota)
# umount /legacy_snap/
# lvremove src/legacy_snap
Do you really want to remove active logical volume src/legacy_snap? [y/n]: y
Logical volume "legacy_snap" successfully removed
# lvs | grep testlv
testlv_bk dst -wi-a----- 30.00g
testlv src -wi-ao---- 200.00g
# rm -f hoge
# echo 3 > /proc/sys/vm/drop_caches
# time cp oracle-database-ee-18c-1.0-1.x86_64.rpm hoge
real 0m36.417s
user 0m0.028s
sys 0m4.258s
# echo 3 > /proc/sys/vm/drop_caches
# time cat oracle-database-ee-18c-1.0-1.x86_64.rpm > /dev/null
real 0m27.765s
user 0m0.025s
sys 0m2.158s
もう一回！
# rm -f hoge
# echo 3 > /proc/sys/vm/drop_caches
# time cp oracle-database-ee-18c-1.0-1.x86_64.rpm hoge
real 0m36.027s
user 0m0.028s
sys 0m4.269s
X-4.シンスナップショットが1個だけ有るソースボリュームのシーケンシャルwrite時間
ソースLVの外部シンプール内にシンスナップショットを作成する際には、ソースLVは非アクティブであり、かつ読み取り専用である必要があります。また外部シンプールのシンスナップショットを削除するまでソースLVを書き込み可能にできません。
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html/configuring_and_managing_logical_volumes/creating_thinly_provisioned_snapshot_volumes
※ソースLVを非アクティブにするには、
lvchange -an src/testlv
ソースLVを書き込み不可にするには、
lvchange -pr src/testlv
逆にソースLVを書き込み可にするには、
lvchange -prw src/testlv
# lvcreate -n thin_snap -s src/testlv --thinpool src/test_thinpool
Using default stripesize 64.00 KiB.
Cannot use writable LV as the external origin.
シンスナップショットが存在している間、ソースLVが書き込みできないというのでは、スナップショットを使ってバックアップが完了するまでダウンタイムになってしまうのでバックアップ中もサービスを提供したいシステムの場合は使えない。なのでこれ以後は、すでにあるシンプール「test_thinpool」内にシンボリュームを作成して、同じシンプール内にシンスナップショットを作成する。
# lvcreate -T src/test_thinpool -V 20G -n thinlv_1
Using default stripesize 64.00 KiB.
Logical volume "thinlv_1" created.
# lvcreate -s --name thin_snap src/thinlv_1
Using default stripesize 64.00 KiB.
WARNING: Sum of all thin volume sizes (40.00 GiB) exceeds the size of thin pool src/test_thinpool (30.00 GiB)!
For thin pool auto extension activation/thin_pool_autoextend_threshold should be below 100.
Logical volume "thin_snap" created.
# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
home cl -wi-ao---- 173.87g
root cl -wi-ao---- 50.00g
swap cl -wi-ao---- 7.81g
dst_2TB_linerlv dst -wi-ao---- 2.00t
testlv_bk dst -wi-a----- 30.00g
src_2TB_linerlv src -wi-ao---- 2.00t
test_thinpool src twi-aotz-- 30.00g 0.00 0.49
testlv src -wi-ao---- 200.00g
thin_snap src Vwi---tz-k 20.00g test_thinpool thinlv_1
thinlv_1 src Vwi-a-tz-- 20.00g test_thinpool 0.00
# mkfs.xfs /dev/src/thinlv_1
meta-data=/dev/src/thinlv_1 isize=512 agcount=16, agsize=327664 blks
= sectsz=4096 attr=2, projid32bit=1
= crc=1 finobt=0, sparse=0
data = bsize=4096 blocks=5242624, imaxpct=25
= sunit=16 swidth=16 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal log bsize=4096 blocks=2560, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
# mount /dev/src/thinlv_1 /mnt
# cp -p /tmp/oracle-database-ee-18c-1.0-1.x86_64.rpm /mnt
# cd /mnt
# pwd
/mnt
# ll
合計 3502208
-rw-r--r--. 1 root root 3586257564 9月 7 10:36 oracle-database-ee-18c-1.0-1.x86_64.rpm
# echo 3 > /proc/sys/vm/drop_caches
# time cp oracle-database-ee-18c-1.0-1.x86_64.rpm hoge
real 0m31.013s
user 0m0.018s
sys 0m4.428s
# echo 3 > /proc/sys/vm/drop_caches
# time cat oracle-database-ee-18c-1.0-1.x86_64.rpm > /dev/null
real 0m20.445s
user 0m0.009s
sys 0m2.288s
もういっかい
# rm -f hoge
# echo 3 > /proc/sys/vm/drop_caches
# time cp oracle-database-ee-18c-1.0-1.x86_64.rpm hoge
real 0m29.105s
user 0m0.015s
sys 0m4.282s
X-5.シンスナップショットが2個だけ有るソースボリュームのシーケンシャルwrite時間
# lvcreate -s -n thin_snap2 src/thinlv_1
Using default stripesize 64.00 KiB.
WARNING: Sum of all thin volume sizes (60.00 GiB) exceeds the size of thin pool src/test_thinpool (30.00 GiB)!
For thin pool auto extension activation/thin_pool_autoextend_threshold should be below 100.
Logical volume "thin_snap2" created.
# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
home cl -wi-ao---- 173.87g
root cl -wi-ao---- 50.00g
swap cl -wi-ao---- 7.81g
dst_2TB_linerlv dst -wi-ao---- 2.00t
testlv_bk dst -wi-a----- 30.00g
src_2TB_linerlv src -wi-ao---- 2.00t
test_thinpool src twi-aotz-- 30.00g 22.30 11.18
testlv src -wi-ao---- 200.00g
thin_snap src Vwi---tz-k 20.00g test_thinpool thinlv_1
thin_snap2 src Vwi---tz-k 20.00g test_thinpool thinlv_1
thinlv_1 src Vwi-aotz-- 20.00g test_thinpool 33.45
# rm -f hoge
# echo 3 > /proc/sys/vm/drop_caches
# time cp oracle-database-ee-18c-1.0-1.x86_64.rpm hoge
real 0m40.248s
user 0m0.027s
sys 0m4.850s
# echo 3 > /proc/sys/vm/drop_caches
# time cat oracle-database-ee-18c-1.0-1.x86_64.rpm > /dev/null
real 0m19.772s
user 0m0.022s
sys 0m2.661s
もういっかい
# rm -f hoge
# echo 3 > /proc/sys/vm/drop_caches
# time cp oracle-database-ee-18c-1.0-1.x86_64.rpm hoge
real 0m32.417s
user 0m0.022s
sys 0m4.877s
なんか速すぎる？
X-3.レガシースナップショットが2個だけ有るソースボリュームのシーケンシャルwrite時間
がクッソ遅かったのでもう一回測る
# cd /
# umount /mnt
# lvremove src/{thin_snap,thin_snap2}
Logical volume "thin_snap" successfully removed
Logical volume "thin_snap2" successfully removed
# lvcreate --size 10G -s -n legacy_snap /dev/src/testlv
Using default stripesize 64.00 KiB.
Logical volume "legacy_snap" created.
# lvcreate --size 10G -s -n legacy_snap2 /dev/src/testlv
Using default stripesize 64.00 KiB.
Logical volume "legacy_snap2" created.
# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
home cl -wi-ao---- 173.87g
root cl -wi-ao---- 50.00g
swap cl -wi-ao---- 7.81g
dst_2TB_linerlv dst -wi-ao---- 2.00t
testlv_bk dst -wi-a----- 30.00g
legacy_snap src swi-a-s--- 10.00g testlv 0.00
legacy_snap2 src swi-a-s--- 10.00g testlv 0.00
src_2TB_linerlv src -wi-ao---- 2.00t
test_thinpool src twi-aotz-- 30.00g 24.27 12.08
testlv src owi-aos--- 200.00g
thinlv_1 src Vwi-a-tz-- 20.00g test_thinpool 36.40
# pwd
/src/1/usr/local/src
# ll oracle-database-ee-18c-1.0-1.x86_64.rpm
-rw-r--r--. 1 root root 3586257564 9月 7 10:36 oracle-database-ee-18c-1.0-1.x86_64.rpm
# rm -f hoge
# echo 3 > /proc/sys/vm/drop_caches
# time cp oracle-database-ee-18c-1.0-1.x86_64.rpm hoge
real 4m14.977s
user 0m0.023s
sys 0m6.402s
もういっかい
# rm -f hoge
# echo 3 > /proc/sys/vm/drop_caches
# time cp oracle-database-ee-18c-1.0-1.x86_64.rpm hoge
real 0m37.779s
user 0m0.024s
sys 0m6.491s
あれっ？速まった
さらにもういっかい
# time rm -f hoge
real 0m58.839s
user 0m0.000s
sys 0m0.554s
ていうか削除すんのにも時間がかかった
# echo 3 > /proc/sys/vm/drop_caches
# time cp oracle-database-ee-18c-1.0-1.x86_64.rpm hoge
real 0m37.156s
user 0m0.035s
sys 0m6.456s
いみふ
# echo 3 > /proc/sys/vm/drop_caches
# time cp hoge fuga
real 0m35.031s
user 0m0.032s
sys 0m6.412s
# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
home cl -wi-ao---- 173.87g
root cl -wi-ao---- 50.00g
swap cl -wi-ao---- 7.81g
dst_2TB_linerlv dst -wi-ao---- 2.00t
testlv_bk dst -wi-a----- 30.00g
legacy_snap src swi-a-s--- 10.00g testlv 67.06
legacy_snap2 src swi-a-s--- 10.00g testlv 67.06
src_2TB_linerlv src -wi-ao---- 2.00t
test_thinpool src twi-aotz-- 30.00g 24.27 12.08
testlv src owi-aos--- 200.00g
thinlv_1 src Vwi-a-tz-- 20.00g test_thinpool 36.40
さらに脱線したくなってきた。
上記のlegacy_snapとlegacy_snap2が約67%の使用率だけど、ソースボリューム上であと一個3.4GBのファイルを新規作成したらスナップショットが溢れるダニ。
ここは溢れさせるダニ。
# md5sum hoge fuga oracle-database-ee-18c-1.0-1.x86_64.rpm
01795d1e5b4f2c9d22b289d1a1ce9b77 hoge
01795d1e5b4f2c9d22b289d1a1ce9b77 fuga
01795d1e5b4f2c9d22b289d1a1ce9b77 oracle-database-ee-18c-1.0-1.x86_64.rpm
# cd /
# umount /src
# xfs_repair /dev/src/testlv
Phase 1 - find and verify superblock...
- reporting progress in intervals of 15 minutes
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
- 07:57:59: scanning filesystem freespace - 27 of 27 allocation groups done
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- 07:57:59: scanning agi unlinked lists - 27 of 27 allocation groups done
- process known inodes and perform inode discovery...
- agno = 0
- agno = 15
- agno = 16
- agno = 1
- agno = 2
- agno = 17
- agno = 3
- agno = 18
- agno = 4
- agno = 19
- agno = 5
- agno = 20
- agno = 6
- agno = 7
- agno = 21
- agno = 8
- agno = 22
- agno = 9
- agno = 23
- agno = 10
- agno = 11
- agno = 24
- agno = 12
- agno = 25
- agno = 13
- agno = 14
- agno = 26
- 07:58:06: process known inodes and inode discovery - 209216 of 209216 inodes done
- process newly discovered inodes...
- 07:58:06: process newly discovered inodes - 27 of 27 allocation groups done
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- 07:58:06: setting up duplicate extent list - 27 of 27 allocation groups done
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- agno = 8
- agno = 9
- agno = 10
- agno = 11
- agno = 12
- agno = 13
- agno = 14
- agno = 15
- agno = 16
- agno = 17
- agno = 18
- agno = 19
- agno = 20
- agno = 21
- agno = 22
- agno = 23
- agno = 24
- agno = 25
- agno = 26
- 07:58:06: check for inodes claiming duplicate blocks - 209216 of 209216 inodes done
Phase 5 - rebuild AG headers and trees...
- 07:58:06: rebuild AG headers and trees - 27 of 27 allocation groups done
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
- 07:58:12: verify and correct link counts - 27 of 27 allocation groups done
done
# mount /dev/src/testlv /src
# cd /src/1/usr/local/src/
# time cp fuga piyo &
# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
home cl -wi-ao---- 173.87g
root cl -wi-ao---- 50.00g
swap cl -wi-ao---- 7.81g
dst_2TB_linerlv dst -wi-ao---- 2.00t
testlv_bk dst -wi-a----- 30.00g
legacy_snap src swi-a-s--- 10.00g testlv 97.48
legacy_snap2 src swi-a-s--- 10.00g testlv 97.48
src_2TB_linerlv src -wi-ao---- 2.00t
test_thinpool src twi-aotz-- 30.00g 24.27 12.08
testlv src owi-aos--- 200.00g
thinlv_1 src Vwi-a-tz-- 20.00g test_thinpool 36.40
# ll
合計 14822732
-rw-r--r--. 1 root root 9 9月 7 10:33 chinko.txt
-rw-r--r--. 1 root root 3586257564 9月 10 07:43 fuga
-rw-r--r--. 1 root root 123711003 9月 7 04:57 go1.14.4.linux-amd64.tar.gz
-rw-r--r--. 1 root root 3586257564 9月 10 07:42 hoge
-rw-r--r--. 1 root root 3586257564 9月 7 10:36 oracle-database-ee-18c-1.0-1.x86_64.rpm
-rw-r--r--. 1 root root 3259150336 9月 10 08:10 piyo
drwxr-xr-x. 3 root root 25 9月 7 04:57 rsync
-rw-r--r--. 1 root root 1069784 9月 7 04:58 rsync-3.2.3.tar.gz
-rw-r--r--. 1 root root 5 9月 7 05:28 unko.txt
あとすこし・・・
real 4m36.452s
user 0m0.036s
sys 0m6.431s
んっ？おわった？
# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
home cl -wi-ao---- 173.87g
root cl -wi-ao---- 50.00g
swap cl -wi-ao---- 7.81g
dst_2TB_linerlv dst -wi-ao---- 2.00t
testlv_bk dst -wi-a----- 30.00g
legacy_snap src swi-I-s--- 10.00g testlv 100.00
legacy_snap2 src swi-I-s--- 10.00g testlv 100.00
src_2TB_linerlv src -wi-ao---- 2.00t
test_thinpool src twi-aotz-- 30.00g 24.27 12.08
testlv src owi-aos--- 200.00g
thinlv_1 src Vwi-a-tz-- 20.00g test_thinpool 36.40
あれっ？エラー吐かない
# md5sum fuga piyo
01795d1e5b4f2c9d22b289d1a1ce9b77 fuga
01795d1e5b4f2c9d22b289d1a1ce9b77 piyo
# mount /dev/src/testlv /src
# cd -
/src/1/usr/local/src
# pwd
# time cp piyo puni
real 0m36.524s
user 0m0.024s
sys 0m6.460s
# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
home cl -wi-ao---- 173.87g
root cl -wi-ao---- 50.00g
swap cl -wi-ao---- 7.81g
dst_2TB_linerlv dst -wi-ao---- 2.00t
testlv_bk dst -wi-a----- 30.00g
legacy_snap src swi-I-s--- 10.00g testlv 100.00
legacy_snap2 src swi-I-s--- 10.00g testlv 100.00
src_2TB_linerlv src -wi-ao---- 2.00t
test_thinpool src twi-aotz-- 30.00g 24.27 12.08
testlv src owi-aos--- 200.00g
thinlv_1 src Vwi-a-tz-- 20.00g test_thinpool 36.40
なんぞ？
# mount /dev/src/legacy_snap /mnt
mount: /dev/mapper/src-legacy_snap: can't read superblock
# mount /dev/src/legacy_snap2 /mnt
mount: /dev/mapper/src-legacy_snap2: can't read superblock
スナップショットだけがお亡くなりになって、ソースボリュームは普通に使えるってことか。
X-5.シンスナップショットが2個だけ有るソースボリュームのシーケンシャルwrite時間
がなんか速すぎる？
スナップショットが何にも無い状態で、シンボリューム「thinlv_1」のシーケンシャルwrite時間を測ってみる
# lvremove /dev/src/legacy_snap
Do you really want to remove active logical volume src/legacy_snap? [y/n]: y
Logical volume "legacy_snap" successfully removed
# lvremove /dev/src/legacy_snap2
Do you really want to remove active logical volume src/legacy_snap2? [y/n]: y
Logical volume "legacy_snap2" successfully removed
# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
home cl -wi-ao---- 173.87g
root cl -wi-ao---- 50.00g
swap cl -wi-ao---- 7.81g
dst_2TB_linerlv dst -wi-ao---- 2.00t
testlv_bk dst -wi-a----- 30.00g
src_2TB_linerlv src -wi-ao---- 2.00t
test_thinpool src twi-aotz-- 30.00g 24.27 12.08
testlv src -wi-ao---- 200.00g
thinlv_1 src Vwi-a-tz-- 20.00g test_thinpool 36.40
# mount /dev/src/thinlv_1 /mnt
# ll /mnt
合計 7004416
-rw-r--r--. 1 root root 3586257564 9月 10 07:17 hoge
-rw-r--r--. 1 root root 3586257564 9月 7 10:36 oracle-database-ee-18c-1.0-1.x86_64.rpm
# cd /mnt
# rm -f hoge
# echo 3 > /proc/sys/vm/drop_caches
# time cp oracle-database-ee-18c-1.0-1.x86_64.rpm hoge
real 0m35.149s
user 0m0.032s
sys 0m4.804s
# lvcreate -s --name thin_snap src/thinlv_1
# lvchange -ay -K /dev/src/thin_snap
# lvs|grep thin_snap
thin_snap src Vwi-a-tz-k 20.00g test_thinpool thinlv_1 36.40
→アクティブフラグが立った
# mount /dev/src/thinlv_1 /mnt
# ll /mnt
合計 7004416
-rw-r--r--. 1 root root 3586257564 9月 10 08:27 hoge
-rw-r--r--. 1 root root 3586257564 9月 7 10:36 oracle-database-ee-18c-1.0-1.x86_64.rpm
# cd /mnt
# rm -f hoge
# echo 3 > /proc/sys/vm/drop_caches
# time cp oracle-database-ee-18c-1.0-1.x86_64.rpm hoge
real 0m33.123s
user 0m0.035s
sys 0m4.871s
# lvextend -L+170G /dev/src/test_thinpool
# lvcreate -s --name thin_snap2 src/thinlv_1
Using default stripesize 64.00 KiB.
Logical volume "thin_snap2" created.
# lvchange -ay -K src/thin_snap2
# mkdir /shin_snap2
# mount -o nouuid /dev/src/thin_snap2 /shin_snap2
# cd /shin_snap2
# ll
合計 7004416
-rw-r--r--. 1 root root 3586257564 9月 10 08:56 hoge
-rw-r--r--. 1 root root 3586257564 9月 7 10:36 oracle-database-ee-18c-1.0-1.x86_64.rpm
# lvs | grep snap
thin_snap src Vwi-a-tz-k 20.00g test_thinpool thinlv_1 36.40
thin_snap2 src Vwi-aotz-k 20.00g test_thinpool thinlv_1 36.40
# cd /mnt
# ll
合計 7004416
-rw-r--r--. 1 root root 3586257564 9月 10 08:56 hoge
-rw-r--r--. 1 root root 3586257564 9月 7 10:36 oracle-database-ee-18c-1.0-1.x86_64.rpm
# echo 3 > /proc/sys/vm/drop_caches
# time cp oracle-database-ee-18c-1.0-1.x86_64.rpm fuga
real 0m33.326s
user 0m0.022s
sys 0m4.818s
# umount /shin_snap2
# mount -o nouuid /dev/src/thin_snap /shin_snap
# mount -o nouuid /dev/src/thin_snap2 /shin_snap2
# echo $?
0
ちゃんとmountできるからお亡くなりになってないのに、シンスナップショットボリュームが2個もつくられてるのにソースボリュームの書き込み速度が遅くなってない？
スナップショットを取得している間、ソースファイルシステムへの書き込み性能がガタ落ちするのはレガシースナップショットだけってこと？
→確かめる方法を考えて確かめよう
もし、シンスナップショットを取得してる間でもソースファイルシステムに対する書き込み性能が劣化しなかったとしたら、LVMスナップショットを利用した従来のバックアップ方法－
つまり、夜中の0時にスナップショットを取得して、取得したスナップショットをマウントして、そこをコピー元にして差分バックアップをコピー先に書き込む方法以外に下記の方法が考えられる？
シンスナップショットボリュームをrwでマウントしてシンスナップショットボリュームに本番データを書き込み、ソースボリュームの方をバックアップにする。もし本番データが破損したり、バックアップ時点のデータを参照したり、本番データをロールバックしたい状況に成ったら、本番データ（シンスナップショットボリューム）からソースボリュームにロールバックする。
# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
home cl -wi-ao---- 173.87g
root cl -wi-ao---- 50.00g
swap cl -wi-ao---- 7.81g
dst_2TB_linerlv dst -wi-ao---- 2.00t
testlv_bk dst -wi-a----- 30.00g
src_2TB_linerlv src -wi-ao---- 2.00t
test_thinpool src twi-aotz-- 200.00g 6.98 25.00
testlv src -wi-ao---- 200.00g
thin_snap src Vwi-aotz-k 20.00g test_thinpool thinlv_1 36.40
thin_snap2 src Vwi-aotz-k 20.00g test_thinpool thinlv_1 36.40
thinlv_1 src Vwi-aotz-- 20.00g test_thinpool 52.65
データもまだ溢れてない。
# cd /shin_snap
# ll
合計 7004416
-rw-r--r--. 1 root root 3586257564 9月 10 08:27 hoge
-rw-r--r--. 1 root root 3586257564 9月 7 10:36 oracle-database-ee-18c-1.0-1.x86_64.rpm
# pwd
/shin_snap
# time cp oracle-database-ee-18c-1.0-1.x86_64.rpm fuga
real 0m33.095s ←遅くない
user 0m0.039s
sys 0m4.861s
# ll
合計 10506624
-rw-r--r--. 1 root root 3586257564 9月 10 09:41 fuga
-rw-r--r--. 1 root root 3586257564 9月 10 08:27 hoge
-rw-r--r--. 1 root root 3586257564 9月 7 10:36 oracle-database-ee-18c-1.0-1.x86_64.rpm
# cd /
# umount /shin_snap
# mount -o nouuid /dev/src/thin_snap /shin_snap
# ll /shin_snap
合計 10506624
-rw-r--r--. 1 root root 3586257564 9月 10 09:41 fuga ←ちゃんといる
-rw-r--r--. 1 root root 3586257564 9月 10 08:27 hoge
-rw-r--r--. 1 root root 3586257564 9月 7 10:36 oracle-database-ee-18c-1.0-1.x86_64.rpm
