I believe the problem you're having is software-related, as distinguished from hardware-related.
Ever since the advent of USB drives, I've noticed that they seem to be particularly susceptible to this kind of "damage" when accidentally disconnected without first removing the icon from the desktop (and thereby updating the drive directory).
....
5. Even if both partitions don't "mount right up", LET IT SIT FOR A WHILE
I think the Finder will try to repair the problem partition, give it 5-10 minutes before giving up. No guarantees, but sometimes this can work with a damaged partition.
...
For those interested in some of the details...
This isn’t just a USB issue. It happens to FireWire drives too. It occurs because when a disk is “unplugged” before it is “unmounted” by the Finder, OS X does not get a chance to update the drive with the latest changes in the directory. This makes that partition's “FILESYSTEM DIRTY”.
Every time a partition is mounted, OS X runs fsck_hfs to check the file system. If everything is OK the log looks like this…
/dev/rdisk0s3: fsck_hfs started at Mon Nov 16 15:28:42 2015
/dev/rdisk0s3: /dev/rdisk0s3: ** /dev/rdisk0s3 (NO WRITE)
/dev/rdisk0s3: Executing fsck_hfs (version hfs-304).
QUICKCHECK ONLY; FILESYSTEM CLEAN
/dev/rdisk0s3: fsck_hfs completed at Mon Nov 16 15:28:42 2015
If not, the log looks something like this…
/dev/rdisk2s3: fsck_hfs started at Fri Jun 13 21:32:52 2014
/dev/rdisk2s3: /dev/rdisk2s3: ** /dev/rdisk2s3 (NO WRITE)
/dev/rdisk2s3: Executing fsck_hfs (version hfs-226.1.1).
QUICKCHECK ONLY; FILESYSTEM DIRTY
/dev/rdisk2s3: fsck_hfs completed at Fri Jun 13 21:32:52 2014
/dev/rdisk2s3: fsck_hfs started at Fri Jun 13 21:32:52 2014
/dev/rdisk2s3: /dev/rdisk2s3: ** /dev/rdisk2s3
/dev/rdisk2s3: Executing fsck_hfs (version hfs-226.1.1).
/dev/rdisk2s3: ** Checking Journaled HFS Plus volume.
/dev/rdisk2s3: The volume name is Seagate 3T
/dev/rdisk2s3: ** Checking extents overflow file.
/dev/rdisk2s3: ** Checking catalog file.
/dev/rdisk2s3: ** Checking multi-linked files.
/dev/rdisk2s3: ** Checking catalog hierarchy.
/dev/rdisk2s3: ** Checking extended attributes file.
/dev/rdisk2s3: ** Checking multi-linked directories.
/dev/rdisk2s3: ** Checking volume bitmap.
/dev/rdisk2s3: Volume bitmap needs minor repair for orphaned blocks
/dev/rdisk2s3: ** Checking volume information.
/dev/rdisk2s3: ** Repairing volume.
/dev/rdisk2s3: ** Rechecking volume.
/dev/rdisk2s3: ** Checking Journaled HFS Plus volume.
/dev/rdisk2s3: The volume name is Seagate 3T
/dev/rdisk2s3: ** Checking extents overflow file.
/dev/rdisk2s3: ** Checking catalog file.
/dev/rdisk2s3: ** Checking multi-linked files.
/dev/rdisk2s3: ** Checking catalog hierarchy.
/dev/rdisk2s3: ** Checking extended attributes file.
/dev/rdisk2s3: ** Checking multi-linked directories.
/dev/rdisk2s3: ** Checking volume bitmap.
/dev/rdisk2s3: ** Checking volume information.
/dev/rdisk2s3: ** The volume Seagate 3T was repaired successfully.
/dev/rdisk2s3: fsck_hfs completed at Fri Jun 13 21:51:58 2014
The fsck_hfs process that attempts to correct the problem can take several minutes. In the testing that I was doing after Mavericks was released (see above), the Segate 3T drive took nearly 20 minutes to finally mount. So patience is a virtue.
In more severe cases the disk may mount with a warning that you should “back up everything you can ASAP” or words to that effect.
—-GetRealBro