very slow fw performance when snapshots active
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi List,
I have an actual CentOS Linux with LVM on hardware RAID1+0.
fs layout looks like this:
[root@C20-DB1-00 ~]# lvs
LV VG Attr LSize Origin Snap% Move Log Copy% LVOpt VG0 -wi-ao 300.00G LVRoot VG0 -wi-ao 43.94G LVSwap VG0 -wi-ao 23.44G
Then I create a snapshot vor VG0/LVOpt with 40 GB size.
Then I edit a 2 GB text file on /opt (XFS filesystem) with vi (just hitting "enter" and save this minor change). This will take minutes to finish the vi during saving.
I see the kcopyd in the process list which fills up the snapshot.
When the snapshot is off then saving the same file with the same minor change will take only seconds.
I understand that snapshots are copy-on-write. But I can't explain why this takes minutes for a 2 GB file which has changed only in a few bytes.
Shouldn't only the changed blocks be copied to the snapshot space? Even if only whole PEs are copied then it shouldn't take only seconds to copy to the snapshot.
- From the actual point of view activating snapshots on this database machine absolutly kills performance.
Did I something wrong on that?
- --
Falko Zurell
Skype: zero_data
/i-d media AG
Ohlauer Stra�e 43
D-10999 Berlin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHFxvWsdVNK8p2VTARArgkAJ9KK9hpQBH6gxhzMQiYdZMH87Q0GwCgwOSy w9tcXzNveVWCnTfB4EO5bKU=
=u+DI
-----END PGP SIGNATURE-----
Hi,
Quoted 4 lines · Falko Zurell
Then I edit a 2 GB text file on /opt (XFS filesystem) with vi (just hitting "enter" and save this minor change). This will take minutes to finish the vi during saving.
This problem is not lvm-related: when opening a file with vim, it reads the entire file into memory (even if the file is 2GB), marks the changes into a .swp file. When saving, vim rewrites the entire file in place, effectively changing 2GB of copy on write blocks. This happens every time, with or without snapshot, the latter being worse because of the cow overhead.
for reading-only very large files, "less" or "more" read files on-demand which is a far more effecient way.
for writing, I don't know any method allowing to safely write a small change into a large file, except using awk or perl parsing (which reads the entire streamed file anyway)
Gabriel