Bug 21960 - Не копирует оооочень большие файлы
: Не копирует оооочень большие файлы
Status: NEW
: Sisyphus
(All bugs in Sisyphus/rsync)
: unstable
: all Linux
: P3 minor
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2009-10-16 13:52 by
Modified: 2014-11-28 20:09 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-10-16 13:52:36
Пытаюсь скопировать файл большого размера (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 From 2010-03-24 19:36:16 -------
У меня не нашлось файловой системы, на которой я мог бы поставить подобный
эксперимент:
$ truncate -s 6E large
truncate: truncating `large' at 6917529027641081856 bytes: File too large
------- Comment #2 From 2010-04-24 23:12:21 -------
Да ну прям.  Старый добрый 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 From 2011-04-04 11:25:56 -------
Вроде вышел багфикс rsync 3.0.8
Может там исправили?
------- Comment #4 From 2011-04-13 01:35:17 -------
(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 From 2014-11-28 20:09:45 -------
В 3.1.1 ничего не изменилось, rsync по-прежнему вычитывает файлы-источники
read'ом.