Bug 21960

Summary: Не копирует оооочень большие файлы
Product: Sisyphus Reporter: Alexey Gladkov <legion>
Component: rsyncAssignee: placeholder <placeholder>
Status: NEW --- QA Contact: qa-sisyphus
Severity: minor    
Priority: P3 CC: dubrsl, glebfm, lav, ldv, mike, placeholder
Version: unstable   
Hardware: all   
OS: Linux   

Description Alexey Gladkov 2009-10-16 13:52:36 MSD
Пытаюсь скопировать файл большого размера (6.6 эксабайт):

$ ssh server 'ls -lah /misc/data'
-rw-r--r-- 1 nobody nobody 6.6E Oct 15 17:41 /misc/data

Это файл с дырками (sparse). Реально в нём данных очень мало.

$ rsync -avPS server:/misc/data ./
receiving file list ... 
1 file to consider
data
   113803264   0%    4.16MB/s 490346472:-8:-8

время как видно, совсем сломано.

Более того, сам файл копируется быстро... но вот после этого rsync что-то делает с приведённом выводом ... дождаться 1% я не смог :)

Если rsync прервать, то он создаст копируемый файл.
Comment 1 Dmitry V. Levin 2010-03-24 19:36:16 MSK
У меня не нашлось файловой системы, на которой я мог бы поставить подобный эксперимент:
$ truncate -s 6E large
truncate: truncating `large' at 6917529027641081856 bytes: File too large
Comment 2 Michael Shigorin 2010-04-24 23:12:21 MSD
Да ну прям.  Старый добрый XFS, как обычно:

$ truncate -s 6E large
$ stat large 
  File: `large'
  Size: 6917529027641081856     Blocks: 0          IO Block: 4096   regular file
Device: 902h/2306d      Inode: 50372477    Links: 1
Access: (0644/-rw-r--r--)  Uid: (  501/    mike)   Gid: (  504/    mike)
Access: 2010-04-24 22:09:07.138738801 +0300
Modify: 2010-04-24 22:09:07.138738801 +0300
Change: 2010-04-24 22:09:07.138738801 +0300
$ df -Th .
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/md2       xfs    806G   79G  728G  10% /home
$ uname -r
2.6.18-ovz-rhel-alt11

Время да, сломано аналогично.
Comment 3 Slava Dubrovskiy 2011-04-04 11:25:56 MSK
Вроде вышел багфикс rsync 3.0.8
Может там исправили?
Comment 4 Dmitry V. Levin 2011-04-13 01:35:17 MSK
(In reply to comment #3)
> Вроде вышел багфикс rsync 3.0.8
> Может там исправили?

Нет, там ничего в этой сфере не изменилось.
Эффективной обработка файлов с дырками без специально написанного на эту тему кода не получится.

С недавних пор cp из coreutils немного обучен:

$ > small && truncate -s 6E large && time strace -P large -P small cp --sparse=always large small && ls -log small
Requested path 'large' resolved into '/mnt/large'
Requested path 'small' resolved into '/mnt/small'
stat("small", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
stat("large", {st_mode=S_IFREG|0644, st_size=6917529027641081856, ...}) = 0
stat("small", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
open("large", O_RDONLY)                 = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=6917529027641081856, ...}) = 0
open("small", O_WRONLY|O_TRUNC)         = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
ioctl(3, FS_IOC_FIEMAP, 0x7fffee10c6c0) = 0
ftruncate(4, 6917529027641081856)       = 0
close(4)                                = 0
close(3)                                = 0
0.00user 0.00system 0:00.00elapsed 133%CPU (0avgtext+0avgdata 3760maxresident)k
0inputs+0outputs (0major+539minor)pagefaults 0swaps
-rw-r--r-- 1 6917529027641081856 Апр 13 01:26 small
Comment 5 Dmitry V. Levin 2014-11-28 20:09:45 MSK
В 3.1.1 ничего не изменилось, rsync по-прежнему вычитывает файлы-источники read'ом.