[Solved] Does gparted's copy filesystem copy errors, too?

[gardyloo]

Perhaps a silly question, but I'm simply not sure of the answer.

The background: My main desktop harddrive started showing some pre-fail behavior during the "fast" SMART tests, and wouldn't complete the "long" SMART tests. Occasionally (usually after a day or so of use), the root (ext4) partition or my user's home partition (also ext4) would remount as 'ro', which forced me to reboot, fsck, and so on, but invariably it'd happen again. A fsck when the drive was "fixed" reported no errors, but they'd quickly crop up again.

So I cloned the entire hard drive to another of the same model, using gparted (from the Siduction live DVD) and stuck the new one in. No problems... for about a day. Then it started having the same problems (including failing the extended SMART tests), and bad sectors upon fsck'ing.

My (perhaps stupid) question is this: The new hard drive was supposed to be new, and shouldn't really be in a pre-fail state, unless it was part of a bad batch. The fact that the extended SMART test keeps failing at apparently the same point sort of indicates the same sort of error in the drive. But the SMART stuff is ONLY for sector/hardware based issues, right? It shouldn't have been affected by cloning the old, failing drive, so far as I know.

Am I just unlucky with these drives, or could there be something more nefarious going on?

[dibl]

You say you "cloned" the drive, but did you actually use the "copy partition" function of GParted?

I can't imagine how GParted would cause the drive to exhibit media failures in SMART -- SMART does not know anything about your filesystem or data, it only looks at the performance of the hdd (thermal, spin-up, head movements, read/write on the media, etc.).  So I think maybe you've been extraordinarily unlucky in your selection of drives.  To be sure, use Hirens or some other tools and do some extensive testing on the bare drive, after you use "dd" to zeroize it.

[gardyloo]

Thanks for the response! Yes, I used gparted's "copy/paste" feature to move my data over. I was surprised it worked so well, but it seems to copy empty space too, which is why I suspected a low-level copying (such as using dd behind the scene), but a very cursory googling hasn't told me what they use.

I'm afraid it's probably simply unluck with the drives. I'll try again with a drive I do a check on first...

[michaa7]

1) I once was really unlucky with a drive which broke one day after buying it. The replacement broke again after one day. When I brought back the second disk (to fetch a third disk) I had to sign an agreement to stand for the costs if further test showed that I did something wrong. I didn't have to pay, both disks were defective. So such sh*t can happen.

2) I wouldn't copy blockwise (as gparted does). Just use "cp -a /from/. /to" on command line.

[dibl]

I have a neighbor with a Win Vista OEM computer and she ran out of disk space, on the old 60GB hdd.  I showed her a 250GB drive to buy, and when she had it, I used Gparted to copy first the OEM "rescue" partition, then her OS partition, then her data partition.  Then from the Windows disk manager I expanded the OS partition first, then the data partition to consume the rest of the drive.  It takes a long time, but it is a very nice way to solve that kind of problem, since the OEMs don't give people a copy of their OS software any more.

[michaa7]

True, that a valid use case for gparted.

[gardyloo]

Thanks for these inputs!

I got yet another hdd, and wanted to try out partimage (via the PING distribution, in this case) way of copying things, just because I didn't want to sit through hours of having something copy a bunch of empty partition space back and forth. Turns out that my initial gparted partitioning of this hdd didn't "take" (upon reboot, the partition table couldn't be read, which took me a while to figure out).

I repartitioned using gparted, but then used rsync to copy over everything from the /, /home, and another partition I had. I then had to edit the /etc/fstab to set the new uuid, and then found I had to edit /boot/grub/grub.cfg by hand, to replace the uuids in there.
A pain, but I learned a lot (I do every time I go through stuff like this, and then promptly forget it), and SO FAR the new drive isn't throwing a bunch of filesystem errors.
I'll mark this as "solved". Thanks again!

[Bequimão]

Hi gardyloo,

With gparted I would shrink to partitions to minimum size and expand them later.

Bequimão