Might not be a firmware issue. You can see your drive's current firmware by opening it's
Property dialog under Device Manager and looking at the
Hardware Ids property on the
Details tab. Firmware is the last number on the first line.
There are several different firmware versions used on ST4000DM000-1F21 drives, but according to Seagate, not all firmware versions for a model number drive product are upgrades, but instead are there to support different parts used in manufacturing runs and, using incorrect firmware can make a drive inoperable.
Firmware is determined by date of manufacture rather than model number, so requires the drive's serial number. You can use
Seagate's Drive Detect tool to retrieve the serial number and check for Firmware updates on internal drives. External support, such as eSATA docks isn't guaranteed. Hard Disk Sentinel can however still read the serial number from those.
Usman Aly :
I ran a deep scan nothing found but lately windows is giving me error on every boot that a disk needs repair. Everytime a partition from the same hard drive. Second my data is getting corrupt so as you said. I started backing it up & during that backup. Drive just died totally one time Hard Disk Sentinel became unresponsive. Had 4 to 6 start & stop counts on each transfer. Still hard Disk Sentinel shows the drive as healthy. During my backup process & writing this my start & stop counts went to 6100 from 6063. As you said yeah the drive is failing & I am going to go for warranty claim if it is covered by 3 years warranty if not than I am going to reformat & repartitions, swap cables & run the tests again.
If you are in the process of adding, moving, or deleting files from your volume when it's host disk disconnects from the system or performs an unscheduled stop / start cycle, the volume's file system is very likely in an inconsistent state due to uncommitted, outstanding changes, which should cause it to be marked
dirty. This can also happen if corruption is detected.
Windows checks the dirty bit on storage volumes during boot and schedules an immediate chkdsk run if a dirty volume is found.
A successful chkdsk completion should clear the dirty bit from a volume.
The problem your drive seems to be experiencing, disconnecting from the system, doesn't seem to be an error that is being detected by SMART routines built into the drive. From the devices' point of view, it may just appear to be a random, unsafe removal of the drive, either temporarily or permanently. Since the failure condition is happening outside of what SMART for the drive is able to ascertain is a problem, it makes sense that the drive could still be reporting a 100% healthy status.
The drive may remain connected with the SATA controller bus, but due to a malfunction of the drive or it's internal controller, be in a state where it cannot respond to some or all of the commands from the system. Windows should be able to handle this, within reason, but during the boot process the system can very easily be in a state where it simply waits for the response from the drive rather than being able to run simultaneous processes. The system may also time-out and stop waiting if left for a long enough period of time.
You've already found the simply solution which is to, power down both the drive and controller it's attached to and then power them back up.
It's hard to ascertain what the drive is doing from your graphs. Clearly they are inconsistent, but the graphs alone can't decisively indicate why.
It could be due to the drive malfunctioning or from normal seeking, such as when transferring many small, randomly located files, or even heavy file fragmentation. It could also be caused by any temporary interruption between the source drive and the target drive, including the target drive being unable to maintain the same data rate.
I trust you're probably correct about most of the inconsistencies being due to the drive malfunctioning.
Usman Aly :
Update:
Drive is also acting weird with the space. I've deleted the data around 700GB it showed the space I gained properly but after the crash & restart files are gone but the space is back where it was. Means it is still showing that 700GB space taken. Any clue why does this happens?
If the partition has been scanned due to Windows marking it as
dirty, the chkdsk scan may have saved any file fragments found. The files found will likely be marked as hidden (Microsoft logic!) You will want to modify the
Folder Options in Windows Explorer to ensure you can see hidden files and folders on your drive, and then go to the partition that appears to have space missing to see if there is a
FOUND.000 or similar hidden folder.
Inside the folder will be any recovered files. It's possible they will be useless, as most users won't know what the files are based on a random file name plus file size, and there is no guarantee the files are complete or otherwise incorrupt. Shouldn't hurt to rename some of them and seeing if they open. 3rd party commercial software can usually be used if you think you have lost data that chkdsk has put into a found folder and is likely more practical than trying to go through and rename files manually.
Usman Aly :
Found out one more thing which I don't know I did by mistake or there was some reason behind it. I have all the partitions as primary. Can this cause issues?
This isn't a problem. You can have up to 4 Primary partitions on one drive when using the MBR partitioning scheme and Microsoft's implementation of GUID Partition Table allows 124 partitions for data use.