Originally published at: https://root.bg/work/прехвърляне-на-sparse-файлове-под-линукс/
[:bg]Здравейте,
Тук идеята е следната :
Имаме bare-metal сървър A и искаме да копираме виртуална машина от него на bare-metal сървър B. Ако виртуалната ни машина е голяма примерно 80GB и връзката между двете машини е на 1GB то трансфера ще отнеме около 20 минути.
Ако виртуалната ни машина реално е голяма 1GB, трансфера пак ще отнеме толкова, защото ние ще прехвърлим всичките 80GB - 79GB от които нули.
В този пост ще споделя начин с tar как да избегнем това досадно прехвърляне на излишни данни на sparse файлове.
Създаване на sparse файл
За теста създадох виртуална машина с големина на хард диска 80GB :stat vm-101-disk-1.qcow2
File: vm-101-disk-1.qcow2
Size: 85912715264 Blocks: 26008 IO Block: 4096 regular file
Device: fd02h/64770d Inode: 46792713 Links: 1
Access: (0640/-rw-r-----) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2018-09-12 09:30:28.543834708 +0300
Modify: 2018-09-12 09:29:06.787111495 +0300
Change: 2018-09-12 09:29:06.787111495 +0300
Birth: -
ls -lah ми вади същата големина :
ls -lha vm-101-disk-1.qcow2
-rw-r----- 1 root root 81G Sep 12 09:29 vm-101-disk-1.qcow2
Обаче du -sh ми показва реално заетото пространство :
du -sh vm-101-disk-1.qcow2
13M vm-101-disk-1.qcow2
Прехвърляне на sparse файл
Стандартните начини на копиране - cp или scp ще копират всичките 80GB :scp vm-101-disk-1.qcow2 192.168.1.2:/var/lib/vz/
vm-101-disk-1.qcow2 0% 603MB 83.5MB/s 16:13 <strong>ETA</strong>
ETA (Estimated time of arrival) е 16-17 минути.
Обаче истинската големина на файла е 13M ?!??!? - 16минути??? 
Ето как може да избегнем това с помощта на tar!
tar cvSzf - vm-101-disk-1.qcow2 | ssh 192.168.1.2 'cd /var/lib/vz/ ; tar xzf -'Идеята е следната :
- c - създаваме архив
- v - виждаме всичко което се архивира
- S - sparse - решението на проблема ни! - (Handle sparse files efficiently)
- z - gzip
- f - името на файла
- x - extract-ваме архива
Това е много полезно за трансфери от отдалечени bare-metal сървъри на големи виртуални машини!
ПС. много е важно да се спазва последователността при tar, за да се избегне евентуално затриване на файла ни.
Специални благодарности на @Румен за идеята![:en]Hello,
The main idea of this is :
We have bare-metal server A and we want to copy the virtual machine from A to bare-metal server B. If the virtual machine is 80GB and the connectivity between the two servers is 1GB the transfer will be ready for 20 minutes.
If our virtual machine is 1GB big, the transfer will still take so much because we will transfer all 80GB - 79GB of which zeros.
In this post I will share a way with tar how to avoid this annoying transfer of redundant data to sparse files.
Create a sparse file
For the test, I created a virtual machine with a size of 80GB hard drive :stat vm-101-disk-1.qcow2
File: vm-101-disk-1.qcow2
Size: 85912715264 Blocks: 26008 IO Block: 4096 regular file
Device: fd02h/64770d Inode: 46792713 Links: 1
Access: (0640/-rw-r-----) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2018-09-12 09:30:28.543834708 +0300
Modify: 2018-09-12 09:29:06.787111495 +0300
Change: 2018-09-12 09:29:06.787111495 +0300
Birth: -
ls -lah shows me this :
ls -lha vm-101-disk-1.qcow2
-rw-r----- 1 root root 81G Sep 12 09:29 vm-101-disk-1.qcow2
But du -sh shows the real size :
du -sh vm-101-disk-1.qcow2
13M vm-101-disk-1.qcow2
Transfer sparse file
Standard copy modes - cp or scp will copy all 80GB :scp vm-101-disk-1.qcow2 192.168.1.2:/var/lib/vz/
vm-101-disk-1.qcow2 0% 603MB 83.5MB/s 16:13 <strong>ETA</strong>
ETA (Estimated time of arrival) is 16-17 minutes.
However, the actual file size is 13M ?!??!? - 16minutes???
Here’s how we can avoid this with the help of tar!
tar cvSzf - vm-101-disk-1.qcow2 | ssh 192.168.1.2 'cd /var/lib/vz/ ; tar xzf -'The main idea is :
- c - create archive
- v - verbose
- S - sparse - the solution of our problem! - (Handle sparse files efficiently)
- z - gzip
- f - name of the file
- x - extract the archive
This is very useful for distant bare-metal servers with big virtual machines!
PS. it is very important to follow the tar sequence to avoid deleting our file.
Thanks to @Румен for the idea![:]