On Tue, Jan 08, 2019 at 11:18:11AM -0500, J C Nash wrote:
> I swapped disks yesterday and then formatted new one ext4. Then copied
> files from home repo of files. About 2 TB, but it went faster than
> when ntfs / fuseblk.
Can you estimate how much faster?
Thanks.
Regards,
Alex Pilon
To
I think we've figured out the isssues with rsync and the various options,
and a good option seems to have been implemented and working for JN.
But if you must know, I mostly use fdisk. I started using gparted a while
ago when aligning disks to 4k boundaries was a pain with fdisk. I still
use
On Tue, Jan 08, 2019 at 09:33:29AM -0500, t...@greenbullfrog.com wrote:
> As hinted-at in the post from Raj, the modern-day partition utility is
> parted (cli). The GUI equivalent is gparted. You can query your drive with:
Pardon me, but how is parted more “modern”? Can you explain? I'm not
sure
Yep. I use gparted quite a bit, though for some (not all) tasks lately I've
found gnome-disk-utility
slightly more user-friendly. And for USB sticks I generally use mint-stick
tools simply because they
are quick and relatively good at telling you what disks are what i.e., don't
have to remember
looks to me the WD is more in need of reformatting than the Seagate,
especially for 4k blocks. You could set the filesytem label with fdisk
without affecting anything, but it wouldn't fix the 512byte logical
blocksize the drive is reporting. Most modern drives now are 4k physical
sectors, using
I recall reformatting the Seagate not long after purchasing. Got lazy with the
WD, but will at some time do this (carefully!). Given the cost of disks today,
if I value my time, I'll probably just buy a new one and format it right away
then copy.
Best, JN
On 2019-01-07 9:59 a.m., Dianne Skoll
Thanks for this.
I did some checking, and Raj's suggestion seems to be confirmed, though there
are some aspects of the reported
information that don't fully make sense, since both disks are USB external
ones. The Seagate 3 Terabyte is a
3.5 inch with external power supply. The Western Digital
Ah that makes sense. I can (possibly) explain this behaviour, I have seen
it before. By default, rsync will compare filesize and timestamp before
deciding to proceed with a full file compare. Somehow your incarnation
seems to think the size and/or timestamp differs, and is moving on to a
My script uses the -auv flags, so I see stuff going on. It was when this stopped
for a very long time at a point where I did not expect that I though it had
hung.
I ran things again, though from a terminal, and when it seemed to hang ran
strace -p
and could see things going on (no copy, just
On 2019-01-06 20:09, Peter Sj??berg wrote:
> On 2019-01-06 5:49 p.m., J C Nash wrote:
> > The title says it. I have rsync set up to run from the Double Commander 2
> > pane file
> > manager. If I select parallel directories of modest size, rsync runs fine.
> > (There are
> > very few or no
If it does the whole directory and then shows the output, it could seem slow.
I wrote a perl wrapper that backs up a whole directory and then prints the
output.
Is seems slower than running rsync manually because there is no output
until the end.
On January 6, 2019 8:10:13 PM Peter Sjöberg
11 matches
Mail list logo
