[opensuse] difference between two disks
I have two disks that should be identical. But Dolphin say there is a 200Gb difference in file size, the "to2" (source) having 1.3 To free when the target have 1.5To free I just run as root: rsync -ai --delete-before /run/media/jdd/intenso5to2/ /run/media/jdd/intenso5to/ with no message (no file transfer) The following text is better read from bottom to top: http://susepaste.org/98227966 fdisk shows the two disk are the same. In fact bough at the same time, two 5Tb usb disks for archiving the du -h show the disk should be the same, and roughly are, but du -d says the contrary summary: 3242684936 intenso5to 3242680980 intenso5to2 any idea what happen, and what I can do to find where are the differences between the two disks? thanks jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 18 January 2018 at 17:45, jdd@dodin.org <jdd@dodin.org> wrote:
I have two disks that should be identical. But Dolphin say there is a 200Gb difference in file size, the "to2" (source) having 1.3 To free when the target have 1.5To free
I just run as root:
rsync -ai --delete-before /run/media/jdd/intenso5to2/ /run/media/jdd/intenso5to/
with no message (no file transfer)
The following text is better read from bottom to top:
fdisk shows the two disk are the same. In fact bough at the same time, two 5Tb usb disks for archiving
the du -h show the disk should be the same, and roughly are, but du -d says the contrary
summary:
3242684936 intenso5to 3242680980 intenso5to2
any idea what happen, and what I can do to find where are the differences between the two disks?
thanks
jdd
which filesystem(s) are on each disk? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 18/01/18 16:57, Richard Brown wrote:
On 18 January 2018 at 17:45, jdd@dodin.org <jdd@dodin.org> wrote:
I have two disks that should be identical. But Dolphin say there is a 200Gb difference in file size, the "to2" (source) having 1.3 To free when the target have 1.5To free
I just run as root:
rsync -ai --delete-before /run/media/jdd/intenso5to2/ /run/media/jdd/intenso5to/
with no message (no file transfer)
The following text is better read from bottom to top:
fdisk shows the two disk are the same. In fact bough at the same time, two 5Tb usb disks for archiving
the du -h show the disk should be the same, and roughly are, but du -d says the contrary
summary:
3242684936 intenso5to 3242680980 intenso5to2
any idea what happen, and what I can do to find where are the differences between the two disks?
thanks
jdd
which filesystem(s) are on each disk?
The other obvious thing is, are there any hard links on the source disk? If so, you'll probably have two copies on the target ... Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 18/01/2018 à 18:21, Wols Lists a écrit :
The other obvious thing is, are there any hard links on the source disk? If so, you'll probably have two copies on the target ...
not that I'm aware of. find . -type f -links +1 -printf '%i %n %p\n' don't find any :-( jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Jan 18, 2018 at 12:33 PM, jdd@dodin.org <jdd@dodin.org> wrote:
Le 18/01/2018 à 18:21, Wols Lists a écrit :
The other obvious thing is, are there any hard links on the source disk? If so, you'll probably have two copies on the target ...
not that I'm aware of.
find . -type f -links +1 -printf '%i %n %p\n'
don't find any
I'd suggest that there are probably sparse files on the original filesystem. By default, rsync does not detect sparse files or handle them specially. To change this behavior, specify '-S' or '--sparse'. -Nick -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 18/01/2018 à 19:41, Nick LeRoy a écrit :
I'd suggest that there are probably sparse files on the original filesystem. By default, rsync does not detect sparse files or handle them specially. To change this behavior, specify '-S' or '--sparse'.
-Nick
no change with --sparse, same disk.file size thanks jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 18/01/2018 à 17:57, Richard Brown a écrit :
which filesystem(s) are on each disk?
the two of them are ext4 jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd@dodin.org composed on 2018-01-19 13:23 (UTC+0100):
the two of them are ext4
Compare outputs of each using tune2fs -l. Do the attributes that are not supposed to be unique match? -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 18/01/2018 à 19:48, Felix Miata a écrit :
jdd@dodin.org composed on 2018-01-19 13:23 (UTC+0100):
the two of them are ext4
Compare outputs of each using tune2fs -l. Do the attributes that are not supposed to be unique match?
You found the main problem. The "Reserved block count" was not the same after setting this reserved count to 0 for the two disks, the size as reported by Dolphin is the same however, there is still the same disk usage difference -- du -s /run/media/jdd/intenso5to* 3242684936 /run/media/jdd/intenso5to 3242680980 /run/media/jdd/intenso5to2 but # du --inodes -s /run/media/jdd/intenso5to* 1667104 /run/media/jdd/intenso5to 1667104 /run/media/jdd/intenso5to2 so some files do not have the exact same size?? thanks jdd http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-01-18 22:46, jdd@dodin.org wrote:
Le 18/01/2018 à 19:48, Felix Miata a écrit :
jdd@dodin.org composed on 2018-01-19 13:23 (UTC+0100):
the two of them are ext4
Compare outputs of each using tune2fs -l. Do the attributes that are not supposed to be unique match?
You found the main problem. The "Reserved block count" was not the same
after setting this reserved count to 0 for the two disks, the size as reported by Dolphin is the same
however, there is still the same disk usage difference
-- du -s /run/media/jdd/intenso5to* 3242684936 /run/media/jdd/intenso5to 3242680980 /run/media/jdd/intenso5to2
but
# du --inodes -s /run/media/jdd/intenso5to* 1667104 /run/media/jdd/intenso5to 1667104 /run/media/jdd/intenso5to2
so some files do not have the exact same size??
In this case, I would use 'mc', one disk in each panel, find directory sizes, and then browse down the directories till finding those that are different. Then find which files are different and why. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
jdd -- ...and then jdd@dodin.org said... % ... % -- du -s /run/media/jdd/intenso5to* % 3242684936 /run/media/jdd/intenso5to % 3242680980 /run/media/jdd/intenso5to2 ... % % so some files do not have the exact same size?? Try something like cd /run/media/jdd/intenso5to && du -ka . | sort -k 2 >/tmp/a cd /run/media/jdd/intenso5to2 && du -ka . | sort -k 2 >/tmp/b diff -bu /tmp/a /tmp/b and see how they compare. Byt sorting by path rather than size, you should have both listings in the same order. I actually have an 8G uSD vfat card that shows 1.3G used with no content that I can find, so this caught my eye :-) I don't think I have quite the same issue, though... HTH & good luck :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 19/01/18 03:45, David T-G wrote:
I actually have an 8G uSD vfat card that shows 1.3G used with no content that I can find, so this caught my eye :-) I don't think I have quite the same issue, though...
I guess you've looked for files with the exFAT hidden attribute, seeing as it's likely to be an MS file system? But have you also looked for things like .trash (nix dot directories)? I found a load of space lost like that once. And I thought emacs had a mode for reading directories? Might be interesting if you can call that up to see what that thinks is there, as opposed to what ls or dir tell you. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/18/2018 10:46 PM, jdd@dodin.org wrote:
however, there is still the same disk usage difference
-- du -s /run/media/jdd/intenso5to* 3242684936 /run/media/jdd/intenso5to 3242680980 /run/media/jdd/intenso5to2
Did you try du's --apparent-size option? Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 19/01/2018 à 09:44, Bernhard Voelker a écrit :
On 01/18/2018 10:46 PM, jdd@dodin.org wrote:
however, there is still the same disk usage difference
-- du -s /run/media/jdd/intenso5to* 3242684936 /run/media/jdd/intenso5to 3242680980 /run/media/jdd/intenso5to2
Did you try du's --apparent-size option?
not yet right now I test the -c (checksum) option - long but should fix the problem (hope :-) jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I couldn't have two identical copies, I give up :-( just hope than nothing important is missed thanks jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/22/2018 09:00 PM, jdd@dodin.org wrote:
I couldn't have two identical copies, I give up:-(
well, you could surely achieve this by creating a copy of the (unmounted!) file system instead of the content therein. E.g. with dd [1], you need the arguments: if=/dev/sdc source device (disk or partition) with the file system to copy of=/dev/sdd destination device to be (over-)written iflag=fullblock a MUST to avoid effects of 'short reads' conv=noerror,sync continue on read errors, pad those with NULs bs=32M faster than using the default block size status=progress get some periodical status on the terminal $ dd \ if=/dev/sdc \ of=/dev/sdd \ iflag=fullblock \ conv=noerror,sync \ bs=32M \ status=progress [1] https://www.gnu.org/software/coreutils/dd Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 23/01/2018 à 08:18, Bernhard Voelker a écrit :
On 01/22/2018 09:00 PM, jdd@dodin.org wrote:
I couldn't have two identical copies, I give up:-(
well, you could surely achieve this by creating a copy of the (unmounted!) file system instead of the content therein. E.g. with dd [1], you need the arguments:
sure, but what for? I have no clue if the original copy do not have some problems... I sometime have weird file names, most probably some utf8 badly converted from other file system that are visible on dolphin by black square (nul?) in the file name. Dolphin refuses do manage them, only * or ? can do, so I can remove them or rename them with simpler values, if I can catch them, but some reappear from time to time, I don't know really why this may - or not - be the problem. anyway I just made an other rsync (same archive, but the target is an other disk) and there is also some difference ghost in the shell?? :-) jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/23/2018 11:44 AM, jdd@dodin.org wrote:
Le 23/01/2018 à 08:18, Bernhard Voelker a écrit :
On 01/22/2018 09:00 PM, jdd@dodin.org wrote:
I couldn't have two identical copies, I give up:-(
well, you could surely achieve this by creating a copy of the (unmounted!) file system instead of the content therein. E.g. with dd [1], you need the arguments:
sure, but what for? I have no clue if the original copy do not have some problems...
I sometime have weird file names, most probably some utf8 badly converted from other file system that are visible on dolphin by black square (nul?) in the file name. Dolphin refuses do manage them, only * or ? can do, so I can remove them or rename them with simpler values, if I can catch them, but some reappear from time to time, I don't know really why
this may - or not - be the problem.
anyway I just made an other rsync (same archive, but the target is an other disk) and there is also some difference
ghost in the shell?? :-)
well, a dd clone doesn't care about what files and file names are inside; it doesn't even know that the data copied is a file system. ;-) Regarding bad file names: even if an application shows it with * or ? or whatever, it should be able to handle the file. You can also rename them to proper names. However, I don't think this affects whether a rsync'ed copy has the same disk usage. As mentioned earlier: use "du --apparent-size ..." to compare the sizes, or use "find -xdev -type f -printf '%s %p\n'" to get a such a list for comparison. It's not the brutto bytes the file system uses for storing a file which is important, but the net content' size. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 23/01/2018 à 13:28, Bernhard Voelker a écrit :
comparison. It's not the brutto bytes the file system uses for storing a file which is important, but the net content' size.
sure, but never the less I have yet to understand why copies made with rsync are not identical :-( but may be for an other time thanks jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/23/2018 01:55 PM, jdd@dodin.org wrote:
sure, but never the less I have yet to understand why copies made with rsync are not identical :-(
they are - from the point of view of the content of the files, and with e.g. -HAXax option also from user/group/permission/hardlink/attributes point of view. Still, the file system may e.g. squeeze 10M of NULs inside a file and therefore store it differently. Therefore, du(1) without the --apparent-size option will show what the file system reports about the size of a file: $ truncate -s1T file $ ls -log file -rw-r--r-- 1 1099511627776 Jan 23 14:12 file $ du -h file 0 file $ du -h --apparent-size file 1.0T file It's just your expectation of du's output which does not match how things work. Misunderstandings like that are e.g. explained here: https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#df-and-du-repo... Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 23/01/2018 à 14:18, Bernhard Voelker a écrit :
On 01/23/2018 01:55 PM, jdd@dodin.org wrote:
sure, but never the less I have yet to understand why copies made with rsync are not identical :-(
they are - from the point of view of the content of the files, and with e.g. -HAXax option also from user/group/permission/hardlink/attributes point of view. Still, the file system may e.g. squeeze 10M of NULs inside a file and therefore store it differently.
including with identical checksum!
Therefore, du(1) without the --apparent-size option will show what the file system reports about the size of a file:
same problem # du --apparent-size -s /run/media/jdd/intenso* 3239147738 /run/media/jdd/intenso4to 3239148282 /run/media/jdd/intenso5to2
It's just your expectation of du's output which does not match how things work. Misunderstandings like that are e.g. explained here:
https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#df-and-du-repo...
the difference between du and df is an other problem: a small file uses sector size room (I speak of static data files, both archives, so no unlinked file AFAIK) curious jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/23/2018 02:54 PM, jdd@dodin.org wrote:
same problem
# du --apparent-size -s /run/media/jdd/intenso* 3239147738 /run/media/jdd/intenso4to 3239148282 /run/media/jdd/intenso5to2
and there's e.g. directories: $ mkdir d1 d2 Create 10000 files in 'd1': $ seq -f "d1/%g" 10000 | xargs touch ... and remove them again: $ rm d1/* now see the difference: $ du -s d1 d2 156 d1 4 d2 Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 23/01/2018 à 20:36, Bernhard Voelker a écrit :
On 01/23/2018 02:54 PM, jdd@dodin.org wrote:
same problem
# du --apparent-size -s /run/media/jdd/intenso* 3239147738 /run/media/jdd/intenso4to 3239148282 /run/media/jdd/intenso5to2
and there's e.g. directories:
$ mkdir d1 d2
Create 10000 files in 'd1':
$ seq -f "d1/%g" 10000 | xargs touch
... and remove them again:
$ rm d1/*
now see the difference:
$ du -s d1 d2 156 d1 4 d2
so even non existent and not openned files can take place... any way to reclame the space? and same with --apparent-size? so is there a way to really compare two mirrored disks to see if the copy is good (ext4)? thanks jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/23/2018 09:00 PM, jdd@dodin.org wrote:
so even non existent and not openned files can take place... any way to reclame the space?
AFAIK no. The only workaround I know is to create a new directory "d1.new", move all remaining entries (if any) from "d1" to "d1.new", then rmdir "d1" and rename "d1.tmp" to "d1".
and same with --apparent-size?
yes, this is /apparent/ size. ;-)
so is there a way to really compare two mirrored disks to see if the copy is good (ext4)?
well, you can check with rsync again, telling it to compare the content as well (file size and time stamps is not good enough!): rsync -HAXaxi --checksum --dry-run SRC/. DST/. If nothing shows up there, then I'd say the backup looks good. Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 23 Jan 2018 22:57:18 +0100 Bernhard Voelker <mail@bernhard-voelker.de> wrote:
On 01/23/2018 09:00 PM, jdd@dodin.org wrote:
so even non existent and not openned files can take place... any way to reclame the space?
AFAIK no. The only workaround I know is to create a new directory "d1.new", move all remaining entries (if any) from "d1" to "d1.new", then rmdir "d1" and rename "d1.tmp" to "d1".
I take it you meant to say 'copy' (cp) rather than 'move' (mv) since move will just change the directory pointers.
and same with --apparent-size?
yes, this is /apparent/ size. ;-)
so is there a way to really compare two mirrored disks to see if the copy is good (ext4)?
well, you can check with rsync again, telling it to compare the content as well (file size and time stamps is not good enough!):
rsync -HAXaxi --checksum --dry-run SRC/. DST/.
If nothing shows up there, then I'd say the backup looks good.
Have a nice day, Berny
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
24.01.2018 03:25, Dave Howorth пишет:
On Tue, 23 Jan 2018 22:57:18 +0100 Bernhard Voelker <mail@bernhard-voelker.de> wrote:
On 01/23/2018 09:00 PM, jdd@dodin.org wrote:
so even non existent and not openned files can take place... any way to reclame the space?
AFAIK no. The only workaround I know is to create a new directory "d1.new", move all remaining entries (if any) from "d1" to "d1.new", then rmdir "d1" and rename "d1.tmp" to "d1".
I take it you meant to say 'copy' (cp) rather than 'move' (mv) since move will just change the directory pointers.
Which is exactly what is necessary here. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave, et al -- ...and then Dave Howorth said... % % On Tue, 23 Jan 2018 22:57:18 +0100 % Bernhard Voelker <mail@bernhard-voelker.de> wrote: % % > On 01/23/2018 09:00 PM, jdd@dodin.org wrote: % > > so even non existent and not openned files can take place... any % > > way to reclame the space? % > % > AFAIK no. The only workaround I know is to create a new % > directory "d1.new", move all remaining entries (if any) from "d1" % > to "d1.new", then rmdir "d1" and rename "d1.tmp" to "d1". % % I take it you meant to say 'copy' (cp) rather than 'move' (mv) since % move will just change the directory pointers. [snip] No, I think he meant move. The problem is that the original "d1" has slots for thousands of files but only a few actually in use, and the fix is simply to create a new directory into which to swing (not copy, same inodes & extents, etcetc) those files before removing the emptied original directory. HTH & HANN :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 23 Jan 2018 23:05:12 -0500 David T-G <davidtg-robot@justpickone.org> wrote:
Dave, et al --
...and then Dave Howorth said... % % On Tue, 23 Jan 2018 22:57:18 +0100 % Bernhard Voelker <mail@bernhard-voelker.de> wrote: % % > On 01/23/2018 09:00 PM, jdd@dodin.org wrote: % > > so even non existent and not openned files can take place... any % > > way to reclame the space? % > % > AFAIK no. The only workaround I know is to create a new % > directory "d1.new", move all remaining entries (if any) from "d1" % > to "d1.new", then rmdir "d1" and rename "d1.tmp" to "d1". % % I take it you meant to say 'copy' (cp) rather than 'move' (mv) since % move will just change the directory pointers. [snip]
No, I think he meant move. The problem is that the original "d1" has slots for thousands of files but only a few actually in use, and the fix is simply to create a new directory into which to swing (not copy, same inodes & extents, etcetc) those files before removing the emptied original directory.
Ah, sorry. I didn't realize the discussion was just about the directories rather than the files.
HTH & HANN
:-D
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd -- ...and then jdd@dodin.org said... % ... % so is there a way to really compare two mirrored disks to see if the % copy is good (ext4)? I forget if we've discussed this before... What about good ol' diff -r $SRC $DST to recurse through both trees? Do you *need* to care if any sparse files have been expanded upon copy (ie are there a lot of them waiting to blow up your target disk space?)? HTH & bonne nuit :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 24/01/2018 à 05:11, David T-G a écrit :
jdd --
% so is there a way to really compare two mirrored disks to see if the % copy is good (ext4)?
I forget if we've discussed this before... What about good ol'
diff -r $SRC $DST
to recurse through both trees? Do you *need* to care if any sparse files have been expanded upon copy (ie are there a lot of them waiting to blow up your target disk space?)?
the to disks are simply archives made mostly trough Dolphin (copy/paste) then mirrored from the first disk (5to2) to the second (4To) diff run after around 24h with 18% processor (there are around 3.5To data) with little differences, but ones I don't understand. # rsync -ai --delete /run/media/jdd/intenso5to2/ /run/media/jdd/intenso4to/ to make sure nothing was changed since last mirror (nothing copied this time) try to remove empty dirs: # find /run/media/jdd/intenso5to2/ -type d -empty -delete # find /run/media/jdd/intenso4to/ -type d -empty -delete but... this is both not completely harmless, because some empty dirs may be relevant, anyway this do not remove hidden dirs and trigger a diff error: diff -r /run/media/jdd/intenso5to2/ /run/media/jdd/intenso4to/ 2> diff-r.txt gives a non empty result: 255370 25 janv. 00:34 diff-r.txt but most if not all are about symbolic links that do not point to anything (due to the copy) https://www.cjoint.com/doc/18_01/HAzgipL8PRh_Screenshot-20180125-070751.png I guess diff tried to follow the links? but also (no such file): diff: /run/media/jdd/intenso5to2/archives-avant-2016/archives-2009-180go/sauf-multimedia/web/data/srv/www/htdocs/cubahoy2009: Aucun fic hier ou dossier de ce type diff: /run/media/jdd/intenso4to/archives-avant-2016/archives-2009-180go/sauf-multimedia/web/data/srv/www/htdocs/cubahoy2009: Aucun fichier ou dossier de ce type and there is no file of this name on any disk, not even link, so from where come the diff message? so no meaningful difference thanks jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2018-01-25 at 07:27 +0100, jdd@dodin.org wrote:
Le 24/01/2018 à 05:11, David T-G a écrit :
% so is there a way to really compare two mirrored disks to see if the % copy is good (ext4)?
I forget if we've discussed this before... What about good ol'
diff -r $SRC $DST
to recurse through both trees? Do you *need* to care if any sparse files have been expanded upon copy (ie are there a lot of them waiting to blow up your target disk space?)?
diff run on the disks themselves? I didn't know that was possible.
the to disks are simply archives made mostly trough Dolphin (copy/paste) then mirrored from the first disk (5to2) to the second (4To)
diff run after around 24h with 18% processor (there are around 3.5To data) with little differences, but ones I don't understand.
Why not post those differences here?
# rsync -ai --delete /run/media/jdd/intenso5to2/ /run/media/jdd/intenso4to/
to make sure nothing was changed since last mirror (nothing copied this time)
try to remove empty dirs:
I would not do that. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlprIXoACgkQtTMYHG2NR9VIIwCdE5mq6RttBO2brB9q6aCuj+q4 suYAoJLVnKY4RqR+KH7IEjzEHVAqFUyu =BW0Z -----END PGP SIGNATURE-----
Le 26/01/2018 à 13:39, Carlos E. R. a écrit :
diff run on the disks themselves? I didn't know that was possible.
I didn't either :-), but it works. However, for 3.5Tb data it's very long (around 12h, not thinked to time it)
Why not post those differences here?
too large. I posted an abstract on an other post most (if not all) where broken symbolic links, looks like diff try to follow the links and, of course, links on a copy are often broken jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/26/2018 03:23 PM, jdd@dodin.org wrote:
most (if not all) where broken symbolic links, looks like diff try to follow the links and, of course, links on a copy are often broken
diff --no-dereference ... Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 26/01/2018 à 17:22, Bernhard Voelker a écrit :
On 01/26/2018 03:23 PM, jdd@dodin.org wrote:
most (if not all) where broken symbolic links, looks like diff try to follow the links and, of course, links on a copy are often broken
diff --no-dereference ...
Have a nice day, Berny
thanks, I will try an other time, too long to be run :-( jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Отправлено с iPhone
23 янв. 2018 г., в 15:55, "jdd@dodin.org" <jdd@dodin.org> написал(а):
Le 23/01/2018 à 13:28, Bernhard Voelker a écrit :
comparison. It's not the brutto bytes the file system uses for storing a file which is important, but the net content' size. sure, but never the less I have yet to understand why copies made with rsync are not identical :-(
One obvious example - file had non-zero block (and so it consumed real storage) which was later overwritten by zeroes. It will continue to consume real block on source, but on destination it is replaced by hole (no storage consumption). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 23/01/2018 à 15:26, Andrei Borzenkov a écrit :
One obvious example - file had non-zero block (and so it consumed real storage) which was later overwritten by zeroes. It will continue to consume real block on source, but on destination it is replaced by hole (no storage consumption).
even with checksum control?? jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
23.01.2018 22:27, jdd@dodin.org пишет:
Le 23/01/2018 à 15:26, Andrei Borzenkov a écrit :
One obvious example - file had non-zero block (and so it consumed real storage) which was later overwritten by zeroes. It will continue to consume real block on source, but on destination it is replaced by hole (no storage consumption).
even with checksum control??
checksums will see zeros in both cases. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 23/01/2018 à 20:29, Andrei Borzenkov a écrit :
23.01.2018 22:27, jdd@dodin.org пишет:
Le 23/01/2018 à 15:26, Andrei Borzenkov a écrit :
One obvious example - file had non-zero block (and so it consumed real storage) which was later overwritten by zeroes. It will continue to consume real block on source, but on destination it is replaced by hole (no storage consumption).
even with checksum control??
checksums will see zeros in both cases.
really curious thanks jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-01-23 20:56, jdd@dodin.org wrote:
Le 23/01/2018 à 20:29, Andrei Borzenkov a écrit :
23.01.2018 22:27, jdd@dodin.org пишет:
Le 23/01/2018 à 15:26, Andrei Borzenkov a écrit :
One obvious example - file had non-zero block (and so it consumed real storage) which was later overwritten by zeroes. It will continue to consume real block on source, but on destination it is replaced by hole (no storage consumption).
even with checksum control??
checksums will see zeros in both cases.
really curious
Think of it as compression, the files are the same, but compressed. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On Tue, 23 Jan 2018 23:13:20 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2018-01-23 20:56, jdd@dodin.org wrote:
Le 23/01/2018 à 20:29, Andrei Borzenkov a écrit :
23.01.2018 22:27, jdd@dodin.org пишет:
Le 23/01/2018 à 15:26, Andrei Borzenkov a écrit :
One obvious example - file had non-zero block (and so it consumed real storage) which was later overwritten by zeroes. It will continue to consume real block on source, but on destination it is replaced by hole (no storage consumption).
even with checksum control??
checksums will see zeros in both cases.
really curious
Think of it as compression, the files are the same, but compressed.
Not a terribly good analogy, since a compressed file will have a different checksum. Where a run of zeros is important, of course people use something more sophisticated than a simple checksum to guarantee integrity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-01-24 01:29, Dave Howorth wrote:
On Tue, 23 Jan 2018 23:13:20 +0100 "Carlos E. R." <> wrote:
On 2018-01-23 20:56, jdd@dodin.org wrote:
Le 23/01/2018 à 20:29, Andrei Borzenkov a écrit :
23.01.2018 22:27, jdd@dodin.org пишет:
Le 23/01/2018 à 15:26, Andrei Borzenkov a écrit :
One obvious example - file had non-zero block (and so it consumed real storage) which was later overwritten by zeroes. It will continue to consume real block on source, but on destination it is replaced by hole (no storage consumption).
even with checksum control??
checksums will see zeros in both cases.
really curious
Think of it as compression, the files are the same, but compressed.
Not a terribly good analogy, since a compressed file will have a different checksum.
Not if it is a compressed filesytem: all the applications see are the (apparently) expanded files, exactly equal to the originals :-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2018-01-22 at 21:00 +0100, jdd@dodin.org wrote:
I couldn't have two identical copies, I give up :-(
just hope than nothing important is missed
Make a listing of both directories and compare them with diff. Was suggested in some post. It will find the differences. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpnPfoACgkQtTMYHG2NR9WEDQCgidminRXlZ8QroX8SYoO6bcPf 8X0An0RXTsXI0bjmTyxuN09UGdDXxZhN =iBWa -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 23/01/2018 à 14:51, Carlos E. R. a écrit :
Make a listing of both directories and compare them with diff. Was suggested in some post. It will find the differences.
I did, but got a long misting I didn't understand :-( jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd@dodin.org wrote:
Le 23/01/2018 à 14:51, Carlos E. R. a écrit :
Make a listing of both directories and compare them with diff. Was suggested in some post. It will find the differences.
I did, but got a long misting I didn't understand :-(
A long diff listing suggests lots of differences. You could post it, someone will no doubt know what it says. -- Per Jessen, Zürich (7.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-01-23 15:07, jdd@dodin.org wrote:
Le 23/01/2018 à 14:51, Carlos E. R. a écrit :
Make a listing of both directories and compare them with diff. Was suggested in some post. It will find the differences.
I did, but got a long misting I didn't understand :-(
Well, then we can work at that, it should be a short list. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 2018-01-23 15:23, Carlos E. R. wrote:
On 2018-01-23 15:07, jdd@dodin.org wrote:
Le 23/01/2018 à 14:51, Carlos E. R. a écrit :
Make a listing of both directories and compare them with diff. Was suggested in some post. It will find the differences.
I did, but got a long misting I didn't understand :-(
Well, then we can work at that, it should be a short list.
You may run find . -ls on the root of each tree, which will print information on each file, relative to the current directory: 193485 4 -rw-rw-r-- 2 news news 1450 Dec 7 2015 ./var_spool_news/alt/linux/suse/2030 193486 4 -rw-rw-r-- 2 news news 1782 Dec 7 2015 ./var_spool_news/alt/linux/suse/2031 193487 4 -rw-rw-r-- 2 news news 1520 Dec 7 2015 ./var_spool_news/alt/linux/suse/2032 193488 4 -rw-rw-r-- 2 news news 1939 Dec 7 2015 ./var_spool_news/alt/linux/suse/2033 File: find.info, Node: Print File Information, Next: Run Commands, Prev: Print File Name, Up: Actions 3.2 Print File Information ========================== -- Action: -ls True; list the current file in `ls -dils' format on the standard output. The output looks like this: 204744 17 -rw-r--r-- 1 djm staff 17337 Nov 2 1992 ./lwall-quotes The fields are: 1. The inode number of the file. *Note Hard Links::, for how to find files based on their inode number. 2. the number of blocks in the file. The block counts are of 1K blocks, unless the environment variable `POSIXLY_CORRECT' is set, in which case 512-byte blocks are used. *Note Size::, for how to find files based on their size. 3. The file's type and file mode bits. The type is shown as a dash for a regular file; for other file types, a letter like for `-type' is used (*note Type::). The file mode bits are read, write, and execute/search for the file's owner, its group, and other users, respectively; a dash means the permission is not granted. *Note File Permissions::, for more details about file permissions. *Note Mode Bits::, for how to find files based on their file mode bits. 4. The number of hard links to the file. 5. The user who owns the file. 6. The file's group. 7. The file's size in bytes. 8. The date the file was last modified. 9. The file's name. `-ls' quotes non-printable characters in the file names using C-like backslash escapes. This may change soon, as the treatment of unprintable characters is harmonised for `-ls', `-fls', `-print', `-fprint', `-printf' and `-fprintf'. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Le 23/01/2018 à 15:56, Carlos E. R. a écrit :
Well, then we can work at that, it should be a short list.
I try again. The two disks are not the same as before, but the files are and also come from rsync --delete linux-owxt:/run/media/jdd/intenso5to2 # ls -aR > ../5t02.txt linux-owxt:/run/media/jdd/intenso5to2 # cd ../intenso4to/ linux-owxt:/run/media/jdd/intenso4to # ls -aR > ../4to.txt linux-owxt:/run/media/jdd/intenso4to # cd .. linux-owxt:/run/media/jdd # diff -b 5t02.txt 4to.txt > diff.txt diff.txt is zero bytes linux-owxt:/run/media/jdd # du --apparent-size -s /run/media/jdd/intenso* 3239147738 /run/media/jdd/intenso4to 3239148282 /run/media/jdd/intenso5to2
find . -ls
linux-owxt:/run/media/jdd/intenso5to2 # find . -ls > ../find5.txt linux-owxt:/run/media/jdd/intenso5to2 # cd ../intenso4to/ linux-owxt:/run/media/jdd/intenso4to # find . -ls > ../find4.txt the size of the to files is not identical, but the size of the file (more than 300Mb) # diff -b find5.txt find4.txt > diff2.txt then diff2.txt is very large, the sum of the two files, for sure the diff syntax is not good what may I do? thanks jdd jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-01-23 21:38, jdd@dodin.org wrote:
Le 23/01/2018 à 15:56, Carlos E. R. a écrit :
Well, then we can work at that, it should be a short list.
I try again. The two disks are not the same as before, but the files are and also come from rsync --delete
linux-owxt:/run/media/jdd/intenso5to2 # ls -aR > ../5t02.txt linux-owxt:/run/media/jdd/intenso5to2 # cd ../intenso4to/ linux-owxt:/run/media/jdd/intenso4to # ls -aR > ../4to.txt linux-owxt:/run/media/jdd/intenso4to # cd .. linux-owxt:/run/media/jdd # diff -b 5t02.txt 4to.txt > diff.txt
diff.txt is zero bytes
Well, "ls -aR" doesn't list file sizes. The list of files are the same, no missing files.
linux-owxt:/run/media/jdd # du --apparent-size -s /run/media/jdd/intenso* 3239147738 /run/media/jdd/intenso4to 3239148282 /run/media/jdd/intenso5to2
The difference is 544 bytes "blocks".
find . -ls
linux-owxt:/run/media/jdd/intenso5to2 # find . -ls > ../find5.txt linux-owxt:/run/media/jdd/intenso5to2 # cd ../intenso4to/ linux-owxt:/run/media/jdd/intenso4to # find . -ls > ../find4.txt
the size of the to files is not identical, but the size of the file (more than 300Mb)
# diff -b find5.txt find4.txt > diff2.txt
then diff2.txt is very large, the sum of the two files, for sure the diff syntax is not good
If the diff is very large, you did not run "find . -ls" at the equivalent directories both times. Display find5.txt and find4.txt, they should look very identical. The difference must be very hard to find. If it is not, then obviously you did not copy identical directory structures. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
jdd -- ...and then jdd@dodin.org said... % % Le 23/01/2018 à 15:56, Carlos E. R. a écrit : % ... % >find . -ls % > % linux-owxt:/run/media/jdd/intenso5to2 # find . -ls > ../find5.txt % linux-owxt:/run/media/jdd/intenso5to2 # cd ../intenso4to/ % linux-owxt:/run/media/jdd/intenso4to # find . -ls > ../find4.txt % % the size of the to files is not identical, but the size of the file % (more than 300Mb) [snip] This won't work because -ls includes the inode number, which will not be the same for a given file on two disks. Here's another case where you could use that cool printf option to pull out only the pieces you need to compare :-) HTH & bonne nuit :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2018-01-23 at 23:08 -0500, David T-G wrote:
...and then jdd@dodin.org said... % % Le 23/01/2018 à 15:56, Carlos E. R. a écrit : % ... % >find . -ls % > % linux-owxt:/run/media/jdd/intenso5to2 # find . -ls > ../find5.txt % linux-owxt:/run/media/jdd/intenso5to2 # cd ../intenso4to/ % linux-owxt:/run/media/jdd/intenso4to # find . -ls > ../find4.txt % % the size of the to files is not identical, but the size of the file % (more than 300Mb) [snip]
This won't work because -ls includes the inode number, which will not be the same for a given file on two disks. Here's another case where you could use that cool printf option to pull out only the pieces you need to compare :-)
Inode number is not the inode count, as in ls -l command? OH, you mean the first number. Crumbs. cer@Telcontar:/home_aux/cer/Documents/benchmarking> find . -ls 158907909 4 drwxr-xr-x 2 cer users 4096 Jan 11 11:20 . 158907918 8 -rw-r--r-- 1 root root 4178 Jan 10 20:12 ./4.4.103-18.41-default.log 158907947 12 -rw-r--r-- 1 cer users 9145 Jan 11 10:59 ./Isengard-sql-bench_20180110-antes.txt 158907948 12 -rw-r--r-- 1 cer users 8602 Jan 11 10:59 ./Telcontar-sql-bench_20180110-antes.txt 158907949 20 -rw-r--r-- 1 cer users 19516 Jan 10 23:41 ./Telcontar-iozone_20180110-antes.txt 158907946 4 -rw-r--r-- 1 cer users 2258 Jan 10 19:52 ./Telcontar-interbench_20180110-antes_y_malo.txt 158907950 20 -rw-r--r-- 1 cer users 19506 Jan 11 00:09 ./Isengard-iozone_20180110-antes.txt Ok, then, adapting another example in the info find page, this: find -printf "%3n %-8u %-8g %8s %T+ %p\n->%l\0" | cat (which fails on the '.' entry, by the way) - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlpobwcACgkQtTMYHG2NR9V75QCgmCJUQVjGsPUTnxn4A4M+Fe/C hSMAniJZzurg/WW6+FX/ebZbJpAHyk8P =gRWe -----END PGP SIGNATURE-----
Carlos & jdd, et al -- ...and then Carlos E. R. said... % % On Tuesday, 2018-01-23 at 23:08 -0500, David T-G wrote: % % >...and then jdd@dodin.org said... % >% % >% Le 23/01/2018 à 15:56, Carlos E. R. a écrit : % >% % >... % >% >find . -ls ... % >This won't work because -ls includes the inode number, which will not be ... % % Inode number is not the inode count, as in ls -l command? Correct; it is not that. % % OH, you mean the first number. Crumbs. Yep :-) % % cer@Telcontar:/home_aux/cer/Documents/benchmarking> find . -ls % 158907909 4 drwxr-xr-x 2 cer users 4096 Jan 11 11:20 . % 158907918 8 -rw-r--r-- 1 root root 4178 Jan 10 20:12 ./4.4.103-18.41-default.log ... % % Ok, then, adapting another example in the info find page, this: % % find -printf "%3n %-8u %-8g %8s %T+ %p\n->%l\0" | cat Interesting... Why bother to null-terminate if you aren't sending to xargs with -0? Although I do see a newline \n in there, so I really should try it ... later. % % (which fails on the '.' entry, by the way) Try find * .??* -printf ... to avoid it. [Hmmm... That might break on weird characters again.] Maybe find ./ -printf ... but I doubt it. Of course, you could always just jump past the first line, too, but that's cheating :-) % % % - -- Cheers, % Carlos E. R. HTH & HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-01-24 12:44, David T-G wrote:
Carlos & jdd, et al --
...and then Carlos E. R. said... % % On Tuesday, 2018-01-23 at 23:08 -0500, David T-G wrote:
... % % Ok, then, adapting another example in the info find page, this: % % find -printf "%3n %-8u %-8g %8s %T+ %p\n->%l\0" | cat
Interesting... Why bother to null-terminate if you aren't sending to xargs with -0? Although I do see a newline \n in there, so I really should try it ... later.
No idea, I just took an example from the documentation; it should be correct ™ Sigh.
% % (which fails on the '.' entry, by the way)
Try
find * .??* -printf ...
to avoid it. [Hmmm... That might break on weird characters again.] Maybe
find ./ -printf ...
but I doubt it. Of course, you could always just jump past the first line, too, but that's cheating :-)
-- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 01/18/2018 05:45 PM, jdd@dodin.org wrote:
I have two disks that should be identical. But Dolphin say there is a 200Gb difference in file size, the "to2" (source) having 1.3 To free when the target have 1.5To free
I just run as root:
rsync -ai --delete-before /run/media/jdd/intenso5to2/ /run/media/jdd/intenso5to/
I use: OPTIONS="--archive --acls --xattrs --hard-links --stats --humanreadable " rsync $OPTIONS --one-file-system /SOURCE/ /DEST/ and sometimes I add "--checksum". I should also add "--sparse", I forgot. -a, --archive archive mode; equals -rlptgoD (no -H,-A,-X) ie: --recursive --links --perms --times --group --owner --devices --specials -- Cheers / Saludos, Carlos E. R. (from openSUSE Malachite, Leap 42.3 x86_64 (ssd)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 18/01/2018 à 19:51, Carlos E. R. a écrit :
On 01/18/2018 05:45 PM, jdd@dodin.org wrote:
I have two disks that should be identical. But Dolphin say there is a 200Gb difference in file size, the "to2" (source) having 1.3 To free when the target have 1.5To free
I just run as root:
rsync -ai --delete-before /run/media/jdd/intenso5to2/ /run/media/jdd/intenso5to/
I use: (...)
yes, me too, most of the time, but this don't seems to fit btrfs (specially .snapshot) there should be some (more) extensive definition of -x, including system folders (sys, proc...) and snapshots like a "only sync a flat file system" jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-01-18 22:16, jdd@dodin.org wrote:
Le 18/01/2018 à 19:51, Carlos E. R. a écrit :
On 01/18/2018 05:45 PM, jdd@dodin.org wrote:
I have two disks that should be identical. But Dolphin say there is a 200Gb difference in file size, the "to2" (source) having 1.3 To free when the target have 1.5To free
I just run as root:
rsync -ai --delete-before /run/media/jdd/intenso5to2/ /run/media/jdd/intenso5to/
I use: (...)
yes, me too, most of the time, but this don't seems to fit btrfs (specially .snapshot)
there should be some (more) extensive definition of -x, including system folders (sys, proc...) and snapshots
like a "only sync a flat file system"
I would never include /dev, /proc/ or /sys. Another useful option is "--one-file-system". With that, you can copy the root filesystem without those directories or /home. --exclude certainly works. I don't use any btrfs, but you just have to exclude the snapshots directory. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Carlos E. R. composed on 2018-01-18 19:51 (UTC+0100):
I use:
OPTIONS="--archive --acls --xattrs --hard-links --stats --humanreadable "
rsync $OPTIONS --one-file-system /SOURCE/ /DEST/
and sometimes I add "--checksum". I should also add "--sparse", I forgot.
-a, --archive archive mode; equals -rlptgoD (no -H,-A,-X) ie: --recursive --links --perms --times --group --owner --devices --specials
I don't understand why archive excludes what it excludes, so on anything I know or suspect has hard links, I typically use: -rlptgoDHAX after perusing the man page yet again. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (11)
-
Andrei Borzenkov -
Bernhard Voelker -
Carlos E. R. -
Dave Howorth -
David T-G -
Felix Miata -
jdd＠dodin.org -
Nick LeRoy -
Per Jessen -
Richard Brown -
Wols Lists