1 (edited by fungus 2009-07-24 19:50:31)

Topic: worried about data loss

I've been patient for about 124 hours now but many others posts from people in far cheerier scenarios indicate that gparted won't resolve for an incredibly long time if ever. I'm worried about data loss.
I'm going to say right now that I was an idiot.

System is Ubuntu Jaunty- Gparted 4.3

disk is 500 GB external harddrive (usb2.0) [western digital]
operation is:
shrink fat32 partition from 500gb to about 250gb
create ntfs partition in the remaining unallocated space
*partition start has not been moved
 
This device holds 190GB of unbacked up, fragmented data.

/var/log/messages reports something like:
[xxxxxx.xxxxxx] sd 0. 0. 0. 0 [sdc] Sense Key : No Sense [current]
[xxxxxx.xxxxxx] info fld 0x0
[xxxxxx.xxxxxx] sd 0. 0. 0. 0 [sdc] Add. Sense: No additional sense information
-repeating every 3 seconds

gparted says it's working on 'shrinking partition' with libparted - the last step of the first partition change.
everything else above that has a green check

Might doing both operations one after the other cause issues?
am I totally screwed?
how long might would you expect this to take?
where can i find the gparted log file?
anyway I can piggyback on the status? I'd be ecstatic to see anything more than the bar bouncing back and fourth.

any thoughts are appreciated

2

Re: worried about data loss

im strongly considering killing the operation and hope it has been stuck on the page file. cut my loses..  try to repair this the best i can.

theres a great deal of oversized files of several gigs. I didn't leave enough free space for the operation to complete in any sort of timely manner.

any advice?

3

Re: worried about data loss

Killing a resizing operation is usually to be avoided, because it can lead to an indeterminate state for the file system and so to make it inaccessible. However, in some cases the operation is stopped for any reason (a software problem, a hardware failure ... ). In this case, perhaps you can't loose more if you cancel the operation. Try to understand if there is any real disk activity (any clicks from the head movement).

Operations on USB drives are always slower than on IDE or SATA connected drives because the interface is much slower (100 hours is rather too long).
Anyway this repeating message isn't normal.

Working on heavily fragmented partitions can be risky, because the operations performed are much more complicated. We always advice to defragment the partitions before trying to resize them. Huge files are a further risk.
High fragmentation makes harder to recover lost material.

We always advice to use the latest stable version of the GParted Livecd. The Ubuntu install cd isn't up to date.

(Moved to the live media section)

*** It is highly recommended to backup any important files before doing resize/move operations. ***

4 (edited by fungus 2009-07-24 19:52:21)

Re: worried about data loss

firstly, this does not need to be in the live media section.
I'm running gparted 4.3 from an updated ubuntu install on a lenovo s10 laptop.

The device is spinning up and indicates steady activity on the led.

the message indicates that the scsi request sense command:
"0h     No Sense     Indicates there is no specific Sense Key information to be reported for the disc drive. This would be the case for a successful command or when the ILI bit is one."

[XXXXXX.XXXXXX] is a constantly changing number. the first part is going sequentially - always rising. the second part seems random. i cant get an exact data extract - no internet connectivity and other flash drives won't mount.

currently i think it identifies the location of the current read/write location on the disc. if it's in bytes, then it should be reaching the end of the disc fairly soon - [520000.999999].

i understand the risks. i want more information from this current operation and dont know how to obtain it. parted log?

5

Re: worried about data loss

Hi!

fungus wrote:

[XXXXXX.XXXXXX] is a constantly changing number. the first part is going sequentially - always rising. the second part seems random. i cant get an exact data extract - no internet connectivity and other flash drives won't mount.

currently i think it identifies the location of the current read/write location on the disc. if it's in bytes, then it should be reaching the end of the disc fairly soon - [520000.999999].

In my machine's /var/log/messages, all messages issued by the kernel start with this  number sequence, e.g.

Jul 27 21:05:27 miranda kernel: [ 2683.183254] IPv4 Input (dropped) IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:0e:0c:64:aa:45:08:00 SRC=192.168.0.37 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=128 ID=761 PROTO=UDP SPT=68 DPT=67 LEN=308

Scrolling up  to the time of boot-up, this counter goes to zero, and comparing it against the system time shows that it simply contains the time - measured in seconds - since booting the machine.
So it has nothing to do with the position on the media - it is merely a time stamp!