• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

barely used drive failing right after formatting to new file system

5pips49

n00b
Joined
Mar 7, 2025
Messages
7
tl;dr almost new drive exhibiting weird behavior after formatting to a new file system. Way to just "nuke" the drive, maybe using Badblocks?

Edit: maybe the first computer that the drive was installed in damaged the drive?

Here is a Linux example:
I have a Sata SSD that was used on a Mac as the boot drive. It was used for about 2 hours of total run time. I used an external 'sata to USB' adapter to connect the drive to my Linux Mint 20.3 Cinnamon, 64 bit via USB. Next,

1) I used Discs or Gparted (can't remember which one) to delete the partitions and replace with one ext4 partition. The program deleted and created that all in one step.

2) I changed the permissions on the folder that showed in ../media/pips/ to read/write for my user account, and for the group, pips, and read-only for "everyone."

3) I wrote some data to the drive using Back In Time. Since it was several gigabytes of data, I could see the progress at the bottom of the "Back In Time gui" moving slowly, and it took more than 5 minutes (I did look at the progress at least a few times). Just now, I went into Back In Time and verified that the "destination" is ../media/pips/...

4) I used rync and the command line to write some data to the drive and output the results of the command to a text file in ../media/pips/... When that was finished and I open the text file with xed, I got an error message that some of the characters were unreadable. So, I ran the command again but with the results to a text file on my OS installed internal drive (not the drive in question) and that completed without incident, and readable results in the text file. I right clicked on the source and the destination and verified that they were the same size and same total number of files.

5) I did all of the above steps yesterday. Today, in Nemo the mounted drive shows full available space. I do see that Back In Time created a folder where it would put all of the backed up files (.../backintime/coolcomputer/pips/1/). But, there is nothing there. Also, the files that I copied using rsync are not there either. This was all looking at the folder via Nemo (the file manager for Linux Mint Cinnamon).

The only thing that was a little unusual is that the drive was powered on all night (it was plugged in).
 
Last edited:
sometimes they go bad and/or had a fault from the factory. RMA it.
 
Could be the usb to sata adapter, but sounds like it's pretty fubar. Can you hook it up internally to something and do a full disk trim? Then setup a partition of maybe 25-50% of the disk size and run a badblocks destructive scan on that. And/or a smart full test.

But yeah, sometimes they fail real early. I had a batch in hosted servers that 50% of them hard failed at 14 days of uptime. Almost on schedule.
 
Could be the usb to sata adapter, but sounds like it's pretty fubar. Can you hook it up internally to something and do a full disk trim? Then setup a partition of maybe 25-50% of the disk size and run a badblocks destructive scan on that. And/or a smart full test.

But yeah, sometimes they fail real early. I had a batch in hosted servers that 50% of them hard failed at 14 days of uptime. Almost on schedule.
Thank you for the idea. I have not had a chance to implement your suggestion. It's small and so with the tone of the posts on here, I don't have high hopes for the drive/ high motivation to work on it.
 
Back
Top