Hello,
I just rsync'd my 1TB partitions formated with jfs filesystem
containing ~720GB data. I saw -3G difference between source and
destination which made me suspect possible dataloss. Also I had
experienced loss of integrity on my previous copies but I did not find
the cause until now.
As command line I used following:
sh-3.2# rsync --verbose --sparse --append-verify --fuzzy --progress
--stats --recursive --times --delete /mnt/miracle /mnt/storage
sh-3.2# rsync --version
rsync version 3.0.3 protocol version 30
Copyright (C) 1996-2008 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
append, ACLs, xattrs, iconv, symtimes
rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. See the GNU
General Public Licence for details.
sh-3.2# uname -a
Linux navi 2.6.31.5-bfs304 #9 Wed Dec 2 02:58:47 EET 2009 ppc GNU/Linux
I ran
navi:/mnt/miracle# foreach i ( "`cat ../miracle.txt`" )
foreach? cksum "$i" >> ../miracle.cksums.txt
foreach? end
miracle.txt has list of files (via find ./ -type f) from original
partition. I did same for storage partition (target)
The results of :
navi:/mnt# diff miracle.cksums.txt storage.cksums.txt | wc -l
were (includes some additional lines due diff):
27232
The original count of files:
navi:/mnt# wc -l miracle.cksums.txt
29266 miracle.cksums.txt
every line matches it's counterpart as seen from diff:
lines 9-17:
32,34c32,34
< 4171132061 137124390 ./music/(2006) the remote viewer [expanded]
[flac]/cd1/01. remote viewing 1.flac
< 2227991181 48164220 ./music/(2006) the remote viewer [expanded]
[flac]/cd1/02. remote viewing 2.flac
< 135428409 132580111 ./music/(2006) the remote viewer [expanded]
[flac]/cd1/03. remote viewing 3.flac
---> 319542521 137124390 ./music/(2006) the remote viewer [expanded]
[flac]/cd1/01. remote viewing 1.flac
> 1127514394 48164220 ./music/(2006) the remote viewer [expanded]
[flac]/cd1/02. remote viewing 2.flac
> 3162510123 132580111 ./music/(2006) the remote viewer [expanded]
[flac]/cd1/03. remote viewing 3.flac
lines 3053-3057:
3901c3901
< 2907853037 8534775038
./storage/video/watching/anime/Ghost_in_the_Shell_S.A.C._Individual_Eleven_[1080p,BluRay,x264,DTS]_-_THORA/Ghost_in_the_Shell_S.A.C._Individual_Eleven_[1080p,BluRay,x264,DTS]_-_THORA.mkv
---> 2744503124 8534775038
./storage/video/watching/anime/Ghost_in_the_Shell_S.A.C._Individual_Eleven_[1080p,BluRay,x264,DTS]_-_THORA/Ghost_in_the_Shell_S.A.C._Individual_Eleven_[1080p,BluRay,x264,DTS]_-_THORA.mkv
lines 15995-16010:
< 2494009766 34132620 ./waffcd/music/Moving Past The
Boundaries/Negative Format - 07 Momentum.flac
< 3598390059 37450226 ./waffcd/music/Moving Past The
Boundaries/Negative Format - 08 Focus.flac
< 3539732869 33544123 ./waffcd/music/Moving Past The
Boundaries/Negative Format - 09 Spectral Analysis.flac
< 1302971449 33702136 ./waffcd/music/Moving Past The
Boundaries/Negative Format - 10 Prototype.flac
< 911935599 42218545 ./waffcd/music/Moving Past The
Boundaries/Negative Format - 11 Heterodox.flac
< 2448079640 50651297 ./waffcd/music/Moving Past The
Boundaries/Negative Format - 12 Probe v2.4.flac
< 3294999483 57501994 ./waffcd/music/Moving Past The
Boundaries/Negative Format - 13 Out Of Phase.flac
---> 3567107295 34132620 ./waffcd/music/Moving Past The Boundaries/Negative
Format - 07 Momentum.flac
> 657686196 37450226 ./waffcd/music/Moving Past The Boundaries/Negative
Format - 08 Focus.flac
> 2695060787 33544123 ./waffcd/music/Moving Past The Boundaries/Negative
Format - 09 Spectral Analysis.flac
> 2466439301 33702136 ./waffcd/music/Moving Past The Boundaries/Negative
Format - 10 Prototype.flac
> 3315348387 42218545 ./waffcd/music/Moving Past The Boundaries/Negative
Format - 11 Heterodox.flac
> 4227463752 50651297 ./waffcd/music/Moving Past The Boundaries/Negative
Format - 12 Probe v2.4.flac
> 2982154944 57501994 ./waffcd/music/Moving Past The Boundaries/Negative
Format - 13 Out Of Phase.flac
As we all know the second field of output from cksum is the size: so
the size matches but the content does not.
Running
navi:/mnt# rsync --recursive --progress --verbose miracle storage
started new copy process with disk speed not cached speed.
This maybe due fuzzy option but append-verify should (?) confirm that
the already existing data matches the appended one (?).
Yours,
--Mikko Kortelainen
Well, as you all professional users know, I had error with these lines which i saw cause 'filesystem full':> Running > navi:/mnt# rsync --recursive --progress --verbose miracle storage > started new copy process with disk speed not cached speed.because they should have been: navi:/mnt# rsync --recursive --progress --verbose miracle/ storage/ with slashes. Running that caused copying of just 1. single file: navi:/mnt# rsync --recursive --progress --verbose miracle/ storage/ sending incremental file list storage/video/series/Sliders full/Season 1/Sliders 1x06 Summer of Love.avi 430743552 100% 16.54MB/s 0:00:24 (xfer#1, to-check=1621/5752) sent 431991665 bytes received 2348 bytes 12895343.67 bytes/sec total size is 808342617848 speedup is 1871.19 navi:/mnt# and as you see the speed is way too fast it could have gone through all the files, so I guess I have got a problem -Mikko 2009/12/4 kordex - <kordex at gmail.com>:> Hello, > > I just rsync'd my 1TB partitions formated with jfs filesystem > containing ~720GB data. I saw -3G difference between source and > destination which made me suspect possible dataloss. Also I had > experienced loss of integrity on my previous copies but I did not find > the cause until now. > > As command line I used following: > sh-3.2# rsync --verbose --sparse --append-verify --fuzzy --progress > --stats --recursive --times --delete /mnt/miracle /mnt/storage > > sh-3.2# rsync --version > rsync ?version 3.0.3 ?protocol version 30 > Copyright (C) 1996-2008 by Andrew Tridgell, Wayne Davison, and others. > Web site: http://rsync.samba.org/ > Capabilities: > ? ?64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints, > ? ?socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, > ? ?append, ACLs, xattrs, iconv, symtimes > > rsync comes with ABSOLUTELY NO WARRANTY. ?This is free software, and you > are welcome to redistribute it under certain conditions. ?See the GNU > General Public Licence for details. > > sh-3.2# uname -a > Linux navi 2.6.31.5-bfs304 #9 Wed Dec 2 02:58:47 EET 2009 ppc GNU/Linux > > I ran > > navi:/mnt/miracle# foreach i ( "`cat ../miracle.txt`" ) > foreach? cksum "$i" >> ../miracle.cksums.txt > foreach? end > > miracle.txt has list of files (via find ./ -type f) from original > partition. I did same for storage partition (target) > > The results of : > navi:/mnt# diff miracle.cksums.txt storage.cksums.txt | wc -l > were (includes some additional lines due diff): > 27232 > > The original count of files: > navi:/mnt# wc -l miracle.cksums.txt > 29266 miracle.cksums.txt > > every line matches it's counterpart as seen from diff: > lines 9-17: > > 32,34c32,34 > < 4171132061 137124390 ./music/(2006) the remote viewer [expanded] > [flac]/cd1/01. remote viewing 1.flac > < 2227991181 48164220 ./music/(2006) the remote viewer [expanded] > [flac]/cd1/02. remote viewing 2.flac > < 135428409 132580111 ./music/(2006) the remote viewer [expanded] > [flac]/cd1/03. remote viewing 3.flac > --- >> 319542521 137124390 ./music/(2006) the remote viewer [expanded] [flac]/cd1/01. remote viewing 1.flac >> 1127514394 48164220 ./music/(2006) the remote viewer [expanded] [flac]/cd1/02. remote viewing 2.flac >> 3162510123 132580111 ./music/(2006) the remote viewer [expanded] [flac]/cd1/03. remote viewing 3.flac > > lines 3053-3057: > > 3901c3901 > < 2907853037 8534775038 > ./storage/video/watching/anime/Ghost_in_the_Shell_S.A.C._Individual_Eleven_[1080p,BluRay,x264,DTS]_-_THORA/Ghost_in_the_Shell_S.A.C._Individual_Eleven_[1080p,BluRay,x264,DTS]_-_THORA.mkv > --- >> 2744503124 8534775038 ./storage/video/watching/anime/Ghost_in_the_Shell_S.A.C._Individual_Eleven_[1080p,BluRay,x264,DTS]_-_THORA/Ghost_in_the_Shell_S.A.C._Individual_Eleven_[1080p,BluRay,x264,DTS]_-_THORA.mkv > > > lines 15995-16010: > > < 2494009766 34132620 ./waffcd/music/Moving Past The > Boundaries/Negative Format - 07 Momentum.flac > < 3598390059 37450226 ./waffcd/music/Moving Past The > Boundaries/Negative Format - 08 Focus.flac > < 3539732869 33544123 ./waffcd/music/Moving Past The > Boundaries/Negative Format - 09 Spectral Analysis.flac > < 1302971449 33702136 ./waffcd/music/Moving Past The > Boundaries/Negative Format - 10 Prototype.flac > < 911935599 42218545 ./waffcd/music/Moving Past The > Boundaries/Negative Format - 11 Heterodox.flac > < 2448079640 50651297 ./waffcd/music/Moving Past The > Boundaries/Negative Format - 12 Probe v2.4.flac > < 3294999483 57501994 ./waffcd/music/Moving Past The > Boundaries/Negative Format - 13 Out Of Phase.flac > --- >> 3567107295 34132620 ./waffcd/music/Moving Past The Boundaries/Negative Format - 07 Momentum.flac >> 657686196 37450226 ./waffcd/music/Moving Past The Boundaries/Negative Format - 08 Focus.flac >> 2695060787 33544123 ./waffcd/music/Moving Past The Boundaries/Negative Format - 09 Spectral Analysis.flac >> 2466439301 33702136 ./waffcd/music/Moving Past The Boundaries/Negative Format - 10 Prototype.flac >> 3315348387 42218545 ./waffcd/music/Moving Past The Boundaries/Negative Format - 11 Heterodox.flac >> 4227463752 50651297 ./waffcd/music/Moving Past The Boundaries/Negative Format - 12 Probe v2.4.flac >> 2982154944 57501994 ./waffcd/music/Moving Past The Boundaries/Negative Format - 13 Out Of Phase.flac > > > As we all know the second field of output from cksum is the size: so > the size matches but the content does not. > > Running > navi:/mnt# rsync --recursive --progress --verbose miracle storage > started new copy process with disk speed not cached speed. > > This maybe due fuzzy option but append-verify should (?) confirm that > the already existing data matches the appended one (?). > > Yours, > > --Mikko Kortelainen >
On Fri, 2009-12-04 at 18:21 +0200, kordex - wrote:> I just rsync'd my 1TB partitions formated with jfs filesystem > containing ~720GB data. I saw -3G difference between source and > destination which made me suspect possible dataloss. Also I had > experienced loss of integrity on my previous copies but I did not find > the cause until now. > > As command line I used following: > sh-3.2# rsync --verbose --sparse --append-verify --fuzzy --progress > --stats --recursive --times --delete /mnt/miracle /mnt/storage> As we all know the second field of output from cksum is the size: so > the size matches but the content does not.OK... can you reproduce the problem by copying some of the source files to a different place on the destination filesystem, or on a different filesystem? What if you use cp instead of rsync? Have you run fsck on the source and destination filesystems?> This maybe due fuzzy option but append-verify should (?) confirm that > the already existing data matches the appended one (?).Yes, when a file transfer is performed. If the destination already has a file that passes the quick check with the source file, no file transfer is performed. In that case, consider --ignore-times to disable the quick check. -- Matt
Testing 3.0G file: sh-3.2# du -h /home/kordex/Microsoft.Windows.7.ULTIMATE.x64.OEM.DVD-BIE.iso 3.0G ? ?/home/kordex/Microsoft.Windows.7.ULTIMATE.x64.OEM.DVD-BIE.iso sh-3.2# mount -o remount,ro /home sh-3.2# fsck.jfs /dev/hdc1 fsck.jfs version 1.1.12, 24-Aug-2007 processing started: 12/5/2009 0.24.4 Using default parameter: -p The current device is: ?/dev/hdc1 Block size in bytes: ?4096 Filesystem size in blocks: ?78142042 **Phase 0 - Replay Journal Log Filesystem is clean. sh-3.2# mount -o remount,rw /home sh-3.2# cksum /home/kordex/Microsoft.Windows.7.ULTIMATE.x64.OEM.DVD-BIE.iso 175236102 3117350912 /home/kordex/Microsoft.Windows.7.ULTIMATE.x64.OEM.DVD-BIE.iso sh-3.2# rsync --verbose --sparse --append-verify --fuzzy --progress --stats /home/kordex/Microsoft.Windows.7.ULTIMATE.x64.OEM.DVD-BIE.iso /home/kordex/bar/ Microsoft.Windows.7.ULTIMATE.x64.OEM.DVD-BIE.iso ?3117350912 100% ? ?8.19MB/s ? ?0:06:02 (xfer#1, to-check=0/1) Number of files: 1 Number of files transferred: 1 Total file size: 3117350912 bytes Total transferred file size: 3117350912 bytes Literal data: 3117350912 bytes Matched data: 0 bytes File list size: 64 File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 3117731558 Total bytes received: 31 sent 3117731558 bytes ?received 31 bytes ?8576978.24 bytes/sec total size is 3117350912 ?speedup is 1.00 sh-3.2# sh-3.2# cksum /home/kordex/bar/Microsoft.Windows.7.ULTIMATE.x64.OEM.DVD-BIE.iso 175236102 3117350912 /home/kordex/bar/Microsoft.Windows.7.ULTIMATE.x64.OEM.DVD-BIE.iso Seems <4GB file went fine. No need to test with cp(1). Testing 5.9GB file: sh-3.2# dd if=/home/kordex/Microsoft.Windows.7.ULTIMATE.x64.OEM.DVD-BIE.iso of=/home/kordex/bar/Microsoft.Windows.7.ULTIMATE.x64.OEM.DVD-BIE.iso conv=notrunc oflag=append sh-3.2# du -h /home/kordex/bar/Microsoft.Windows.7.ULTIMATE.x64.OEM.DVD-BIE.iso 5.9G ? ?/home/kordex/bar/Microsoft.Windows.7.ULTIMATE.x64.OEM.DVD-BIE.iso sh-3.2# cksum /home/kordex/bar/Microsoft.Windows.7.ULTIMATE.x64.OEM.DVD-BIE.iso 362659186 6234701824 /home/kordex/bar/Microsoft.Windows.7.ULTIMATE.x64.OEM.DVD-BIE.iso sh-3.2# rsync --verbose --sparse --append-verify --fuzzy --progress --stats /home/kordex/bar/Microsoft.Windows.7.ULTIMATE.x64.OEM.DVD-BIE.iso /home/kordex/bar/foo/ Microsoft.Windows.7.ULTIMATE.x64.OEM.DVD-BIE.iso ?6234701824 100% ? ?9.03MB/s ? ?0:10:58 (xfer#1, to-check=0/1) Number of files: 1 Number of files transferred: 1 Total file size: 6234701824 bytes Total transferred file size: 6234701824 bytes Literal data: 6234701824 bytes Matched data: 0 bytes File list size: 64 File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 6235463006 Total bytes received: 31 sent 6235463006 bytes ?received 31 bytes ?9454834.02 bytes/sec total size is 6234701824 ?speedup is 1.00 sh-3.2# sh-3.2# cksum /home/kordex/bar/foo/Microsoft.Windows.7.ULTIMATE.x64.OEM.DVD-BIE.iso ?362659186 6234701824 /home/kordex/bar/foo/Microsoft.Windows.7.ULTIMATE.x64.OEM.DVD-BIE.iso They seem to match too. No need for cp(1). I will continue tests to my /mnt/miracle and /mnt/storage by tomorrow. 2009/12/5 Matt McCutchen <matt at mattmccutchen.net>:> On Fri, 2009-12-04 at 18:21 +0200, kordex - wrote: >> I just rsync'd my 1TB partitions formated with jfs filesystem >> containing ~720GB data. I saw -3G difference between source and >> destination which made me suspect possible dataloss. Also I had >> experienced loss of integrity on my previous copies but I did not find >> the cause until now. >> >> As command line I used following: >> sh-3.2# rsync --verbose --sparse --append-verify --fuzzy --progress >> --stats --recursive --times --delete /mnt/miracle /mnt/storage > >> As we all know the second field of output from cksum is the size: so >> the size matches but the content does not. > > OK... can you reproduce the problem by copying some of the source files > to a different place on the destination filesystem, or on a different > filesystem? ?What if you use cp instead of rsync? ?Have you run fsck on > the source and destination filesystems? > >> This maybe due fuzzy option but append-verify should (?) confirm that >> the already existing data matches the appended one (?). > > Yes, when a file transfer is performed. ?If the destination already has > a file that passes the quick check with the source file, no file > transfer is performed. ?In that case, consider --ignore-times to disable > the quick check. > > -- > Matt > >