1 Topic by CrashConnoisseur404 (edited by CrashConnoisseur404 2024-01-24 15:40:00)

  • CrashConnoisseur404
  • New member
  • Offline
  • Registered: 2024-01-24
  • Posts: 3

Topic: Crash after checking disk for 2+ weeks, overwritten progress text

Hello GParted Community,

I'm encountering a complex issue with my new Seagate One Touch 8TB external hard drive (USB external), formatted with an ext4 file system. I'm seeking your expertise for a resolution. Here's a detailed breakdown of the events:

Alle pictures referenced can be found here in chronological order: https://imgur.com/a/f3DBFxh

1. Initial File Transfer: Successfully transferred hundreds of gigabytes to the new disk on Ubuntu 22.04.

2. Access Problem: Suddenly, a large folder with many subfolders and files couldn't be opened. An error message appeared, but I don't recall its exact wording as this was a while ago.

3. File System Error Suspected: The disk was new, passed Disk Utility checks, and other files were accessible. There were no bad sectors found. This suggests to me a file system error, not physical damage. There were no indications of physical error, and the disk was brand new.

4. First Repair Attempt: Used GParted Live on a MacBook with 16GB RAM. The repair process stalled overnight due to increasing memory usage.

5. Second Repair Attempt: Connected the disk to an iMac with 64GB RAM, running Ubuntu 22.04 LTS (GParted version 1.3.1). The GParted GUI froze during and produced overwritten/garbled text on the line after it said "Pass 5: Checking Group Summary Information" (See Picture 1).

6. Extended Operation and Memory Fluctuation: The process ran for weeks, with memory usage fluctuating between 35GB and 45GB at about two weeks (Pictures 2 and 3). GParted alternated between normal and unresponsive states with Ubuntu saying Gparted was unresponsive (Picture 4).

7. Disk Activity: After 16 days,  I checked disk read/write activity via htop and System Monitor (Pictures 5 and 6). Does not indicate much has happened.

8. Final Outcome: GParted crashed on the iMac, similar to the GParted Live attempt. (Picture 7) 'gparted.bin' consistently used 100% CPU. The disk's LED was on, but without noise or heat emission from the disk itself.

Post-crash, the partition is unmountable (says "Structure needs cleaning")., suggesting some incomplete changes were made during the scan. (Picture 8) No further information was available from the GParted GUI after the occurrence of the overwritten/garbled text i mentioned in point '5. Second Repair Attempt:' (Picture 1).

I am looking for guidance or suggestions on how to proceed and would appreciate any assistance.

Is is possible that the process is getting stuck because it has to read/write to the same disk and thus grinds to a halt, and therefore I would get better results with buying a new disk and doing a transfer&repair?

Thank you for your time and help.


Edit: 24.1.24: added "("Structure needs cleaning")" in section after 8.

2 Reply by mfleetwo

  • mfleetwo
  • Developer
  • Offline
  • Registered: 2012-05-18
  • Posts: 477

Re: Crash after checking disk for 2+ weeks, overwritten progress text

It sounds like the file system check operation is generating a lot of terminal output and GParted is taking a long time and too much memory to process it.  It might just be that fsck is taking a long time to run (days?) and therefore updating the progress bar is producing a lot of output.  I recommend not using GParted and running fsck manually on the command line.

From the command line to this:

script
sudo e2fsck -f -y -v -C 0 /dev/sdc1
exit

This will log everything that is written to the terminal to a file called typescript in the current directory.  Expect it to be very large.

3 Reply by CrashConnoisseur404 (edited by CrashConnoisseur404 2024-01-24 23:05:11)

  • CrashConnoisseur404
  • New member
  • Offline
  • Registered: 2024-01-24
  • Posts: 3

Re: Crash after checking disk for 2+ weeks, overwritten progress text

mfleetwo wrote:

It sounds like the file system check operation is generating a lot of terminal output and GParted is taking a long time and too much memory to process it.  It might just be that fsck is taking a long time to run (days?) and therefore updating the progress bar is producing a lot of output.  I recommend not using GParted and running fsck manually on the command line.

From the command line to this:

script
sudo e2fsck -f -y -v -C 0 /dev/sdc1
exit

This will log everything that is written to the terminal to a file called typescript in the current directory.  Expect it to be very large.

Hello mfleetwo,

Thank you for your input.

I let the scan run for approximately 3-4 weeks, which seemed unusually lengthy and raised my suspicions. Notably, the garbled text under "Pass 5" (as seen in Picture 1) appeared after just a few hours and persisted until the scan ultimately crashed due to memory exhaustion 3-4 weeks later. Throughout this period, the progress bar (visual/GUI bar) remained stuck at almost complete and did not advance further. This stagnation, combined with the minimal I/O activity (or lack thereof, as shown in Pictures 5 and 6), leads me to suspect that there might be a fundamental software issue (bug) beyond just a lengthy repair process.

Since then, I have purchased a new, identical disk to attempt cloning the original disk. This step is taken to avoid any further potential damage during repair attempts. I'm exploring strategies that are more efficient than simply cloning and then attempting to repair the second disk. Specifically, I'm interested in knowing if there are any modes or commands that facilitate copying and repairing on-the-fly. This approach, I believe, could be more efficient than having GParted read, store, and repair data in memory before writing it back to the same disk. My hope is that such an approach might reduce the memory load and expedite the repair process. (but then again, I don't understand why the memory use was increasing steadily (while fluctuating heavily in the moment) while the scan was running - what operation explains this. Not a continuous read-repair-write back pattern, i presume...)

Any insights or suggestions regarding this strategy would be highly appreciated.

Thank you once again for your time and assistance.

4 Reply by CrashConnoisseur404

  • CrashConnoisseur404
  • New member
  • Offline
  • Registered: 2024-01-24
  • Posts: 3

Re: Crash after checking disk for 2+ weeks, overwritten progress text

Does anybody have experience with "repair on the fly" during the cloning process. Would this approach be more effective than traditional cloning followed by repair? If so, what tools would you recommend? I've heard of Clonezilla and ddrescue but am open to suggestions, especially if there are specific commands or flags that could facilitate this process.

Furthermore, are there tools other than gparted/fsck known for their efficiency in rescuing or repairing files/filesystems and transferring them to a new disk?