How to Fix My External SSD

Support and Help
,
1

Ubuntu Support Template

Ubuntu Version: 24.04.4

Desktop Environment (if applicable):
KDE Plasma

Problem Description:

  1. Using Dolphin, trying to move multiple large directories, 100+ Gig, from my external SSD to trash.

Previously, this operation was almost instantaneous. Now it takes quite a bit longer, maybe half a minute. My previous experience with this was with 24.04.3.

  1. Also, an application I am using reports the following:

image
image588Ă—274 39.5 KB

I have seen this message twice, once before rebooting, once after.

This information is false. The drive being written to is an external SSD, dev/sda1.

$ df /dev/sda1
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 3906966528 2338753536 1568212992 60% /media/scohen/Extreme Pro

There is plenty of room to write this much data.

The creator of this application says the problem lies with my OS. I believe him, especially in light of #1 above. I further think the problem lies with the external SSD.

I’ve Googled for Info on fixing issues with external SSDs on Linux . But they seem to assume the SSD is using the ext4 file system. Mine isn’t:

sudo fdisk -l /dev/sda1
Disk /dev/sda1: 3.64 TiB, 4000751370752 bytes, 7813967521 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 2097152 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device Boot Start End Sectors Size Id Type
/dev/sda1p1 4294967295 8589934589 4294967295 2T ff BBT
/dev/sda1p2 4294967295 8589934589 4294967295 2T ff BBT
/dev/sda1p3 4294967295 8589934589 4294967295 2T ff BBT
/dev/sda1p4 4294967295 6854241533 2559274239 1.2T ff BBT

Note that Disklabel type: dos. And this list of partitions looks really weird. It says the partitions occupy a total of 7.2 T when the drive is only 4T.

I suppose I could reformat the disk but I do not want to lose the data on it and I don’t have that much room available elsewhere.

What tools are available to analyze this and fix this problem with my external SSD given its current formatting and without reformatting the disk?

Relevant System Information:It’s a SanDisk 4TB external SSD

Screenshots or Error Messages:
see above

What I’ve Tried:

Rebooting the machine did not help.

Before Posting:

1 Like
2

BBT, according to a quick google search, seems to be “Xenix bad-block table”. The name suggests corruption.

Which filesystem is it supposed to have? If NTFS better connect it to a Windows machine and use its drive error correction tools. If it can’t correct it the drive is likely faulty.

1 Like
3

Did you keep any record of what you had originally “built” as partitions on that disk, when originally partitionned into 4 partitions? If so, now is the time to find the detailed report for the start/end blocks for each of those partitions.


If you kept the report of when the disk was “clean”, then you would have something that looks like this:

Typical GPT fdisk report 
::::::::::::::
sda/OasisMega1_sda_20240705-172527.350809739_gdisk.txt
::::::::::::::
GPT fdisk (gdisk) version 1.0.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 3907029168 sectors, 1.8 TiB
Model: WDC WD20EZRX-00D
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): AEF7D44F-5EC0-4ABA-B001-54B0DBACCA27
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 8-sector boundaries
Total free space is 16156816 sectors (7.7 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         2099199   1024.0 MiB  EF02  GRUB
   2         2099200         4196351   1024.0 MiB  8200  DB001_S1
   3        16779264       426378873   195.3 GiB   EF00  DB001_F1
   4       426379264       622566944   93.5 GiB    8300  DB001_F8
   7       622566945      1236972869   293.0 GiB   0700  DB001_F2
   8      1236972870      1851378794   293.0 GiB   0700  DB001_F3
   9      1851378795      2465784719   293.0 GiB   0700  DB001_F4
  10      2465784720      2467824974   996.2 MiB   8200  DB001_S2
  11      2467824975      2469865229   996.2 MiB   8200  DB001_S3
  12      2469865230      2879458469   195.3 GiB   0700  DB001_F5
  13      2879458470      3289051709   195.3 GiB   0700  DB001_F6
  14      3289051710      3903457634   293.0 GiB   0700  DB001_F7

As for all my records, for reference, I keep those as seen below:

Failsafe References with fdisk/gdisk reports at partition setup

SNAPSHOT__DiskPartitioningRecords
SNAPSHOT__DiskPartitioningRecords717Ă—660 149 KB


That tells me that your partition table is corrupt.

The start sector is the same for all 4 partitions. Each start and end should be unique!!!

The values for partitions 1, 2 and 3 are identical, which explains both the same 2TB size for each, totalling 6T, but their “space sharing” is the definitive pointer to corruption of the partition table.

If you probe the drive with gdisk do you happen to see anything different?


Also, without making modifications, what do you see when opening GParted, and letting that review/display the SSD’s partitions?


Are you aware that it is much more efficient, safer, and faster, to perform that operation directly from the command-line, using the form

            (WARNING: To be used only when you absolutely know
            what you are doing and accept the irrevocable nature
            of the action!             NO RECOVERY POSSIBLE …
            except from previously-created backup!!!)

sudo rm -rf "${fullPathToDefunctDir}"

NEVER use that command with “.” !


Are you trying to preserve what is on that disk?
          or         is re-formating an option?

Does that disk need to be readable from a Windows OS,
          or         is your system Linux-only?


There is a tool out there specifically to scan a drive and rebuild partitions. That tool is

You might want to investigate before commiting to pursuing that approach.

3 Likes
4

One thing I would check first: run the partition commands against the disk, not the partition. sudo fdisk -l /dev/sda1 is reading inside sda1, so the strange BBT entries may just be misleading output; compare with lsblk -f /dev/sda and sudo fdisk -l /dev/sda. If it is NTFS/exFAT, unmount it before any repair and preferably check it from Windows or the vendor tool, because repairing the wrong device name is the easy way to make this worse.

1 Like
5

Do you get any different output when you run on the drive (/dev/sda) rather than the partition? A dos disklabel is only able to see/access 2TB so I”m curious as to why that exists as I can’t imagine it would be dos from the factory.

Are you sending files/folders on the SSD to a trash folder on that same SSD? What is the point of duplicating on the same drive? It would be useful to indicate the filesystem type, if it is linux or other.

1 Like
6

Thanks for this, Eric.

No (sigh), I did none of these things when I first got the SSD. I just started using it. Live and learn.

I thought that looked like corruption and the source of my problems.

Thanks for all the suggestions, but I have found a different path. I got rid of a lot of unnecessary stuff that was on the drive, and now I have enough room to temporarily move everything off.

Then I will reformat the disk, carefully do the steps I should have done before, and then put it back on the new drive.

3 Likes
7

I did whatever Dolphin’s Move To Trash option does. Yes, that does appear to move stuff to a Trash folder on the drive from which it came.

This is all Linux.

1 Like
8

Unless there is a setting to auto-purge on shutdown, that option is impractical, especially for the volumes of data which you mentionned. That GUI “move-to-Trash” function is really only intended for small stuff, giving Users a “recovery path” in case you accidentally deleted something you didn’t realize that you needed to keep.

3 Likes
9

Obviously, I wasn’t. Lesson learned. I saw this myself, when, according to my new plan of copying everything off, I tried doing it with Dolphin. Dog slow. I gave up on that and did on the command line. So much faster.

Dolphin is convenient but I need to up my game. I do this frequently.

3 Likes
10

First, don’t use the device node names directly; there is no guarantee that they are persistent across restarts, so you might be looking at a different device, when you reboot and pull that command from the history and repeat it.

The real problem seems to be that you directed fdisk to the first partition on your device and it seems to find another (nested) partition table, or at least misinterprets what’s there.

Run it like this:

sudo fdisk -l /dev/sda

(NO number at the end)

As for your space problem and the “moving to trash” taking actual I/O time, that’s most probably caused by the Trash folder residing on your $HOME, which is probably close to bursting. Usually, you shouldn’t need to move things to trash, just delete files and Dolphin will move them to the local trash folder on the corresponding device, which is an almost instant action, because no data is actually moved around; just some bookkeeping to link them to the trash folder and then unlink them from where you deleted them.
You should keep an eye out for the actual confirmation dialog and what it says. I’m not a KDE and thus not a Dolphin user, but I am fairly certain that it will warn you if it can’t move things to trash which would make your deletion irrevocable; in GNOME Files the button turns red in that case and the message says “permanently delete?”.

Moving data from the external device to your $HOME’s trash does require copying it first, hence the delay and your out of space warning.

Why didn’t you click on “Show Details…”? :wink:

I bet that this will reveal the cause of the “out of space message”:

df -h "$HOME"

And are you aware that action is irrevocable? :warning: There is no detour to the Trash purgatory, so no way of restoring files, which is the purpose of Trash to begin with.

Usually one can circumvent the Trash by pressing ShiftDel in the desktop file manager, if that’s what is actually desired.

Please put all log and other console/terminal output in pre-formatted code blocks (open a new line, click the </> icon in the editor first and paste into the new element), ideally wrapped in a “Hide Details” element, if it’s more than just a few lines. See items 4 and 5 in the Posting Guide.

Optional helper script

If you are so inclined, I took it upon myself to provide a little helper script for that. :sweat_droplets:

1 Like
11

I removed Help from the title as the category is Support and Help

4 Likes
12

I do not delete that much data, but some larger files gave similar issue.
I had ot increase the size of trash and regularly houseclean trash to make more space.

What is size limit of your trash?
I use Kubuntu and then in Dolphin and click on trash properties, it says 10% or for me about 6GB.

1 Like
13

My case is a bit unusual. My machine is used mostly (at least data size-wise) for astrophotography. Images are captured hundreds at a time, each 40MB with several processes performed on them in sequence in a one-to-one match with the original image, but twice the size of the originals. That’s quite a lot to clean up and I don’t always do it right away because I might want to improve on the finished product, which might require additional images be captured and added to the mix. Needless to say, I’m not the average user. And the images also have to be moved in the first place from the controller box where they are originally acquired, a raspberry-pi like device, to my computer. So, Dolphin is convenient (it has built-in sftp) but I might be better with scripts for mass deletion but it would be more of a pain to type in the source and destination directories which are always different all the time.

1 Like
14

FYI, you can also trash files from a shell (script):

sudo apt install trash-cli

Not if you know your shell game, or up it. :wink: The great thing about Bash and many other interactive shells is Tab (menu) completion (almost) everywhere. Or use advanced glob patterns; apparently **, for recursive globbing in sub directories, is still an undocumented feature of Bash.
I’m been using the Z-Shell with a rather fantastic config for nigh on 20 years now, though, which, I believe, pioneered ** and I can just do this:

% trash ~/Photos/**/dont_like_*.jpg

(using the default Zsh prompt to avoid confusion; this should work in Bash too, though)
The equivalent POSIX way of doing similar is something like this:

find ~/Photos -name dont_like_\*.jpg -exec trash {} \+

That’s why Linux systems are considered so powerful. If it’s tedious and repetitive, just script it. IIRC, you said something about having been a developer before retirement, so have at it. :man_superhero:

1 Like
15

That was the whole point … avoiding the overhead processing involved in indexing what is transferred to the Trashcan, not to mention immediate release of space associated with the purged items.

I’ve added a warning that can’t be missed.

3 Likes
16

But I take issue with this:

You can’t say it’s safer – with rm -f, no less(!) – when the initial intent was:

trash "${fullPathToDefunctDir}"

What if the user got their wires crossed and directed that command to the wrong location? With your command and async DISCARD/TRIM for SSD’s those files are gone for good, no chance of recovery whatsoever; hence Trash.
In the olden days of spinning rust, they might have stood a chance with testdisk but not with SSD’s.

Repeat after me: rm -f is to be considered harmful! :wink:
I, for one, have this alias, to save me from the worst:

alias rm='rm -I'

and so may other users; -f will override that and silence any non-fatal error, i.e. “do you really want to delete that write-protected file?”. Try it on any random Git repository to see what I mean. :slight_smile:

1 Like
18

The rm -f is a useful command but it is also very dangerous. If anyone is going to recommend using it please use a warning for example.

If you make one mistake you can erase all your files or even your operating system.

Never post that it is safer because that is totally false.

Please only offer the use of this command if it is absolutely necessary.

Always remember that you need to start out with the premise that the OP is new to Ubuntu and has no experience.

4 Likes
19

This topic was automatically closed after 30 days. New replies are no longer allowed.