Choose style:

Author Topic: SSD error  (Read 2000 times)

0 Members and 1 Guest are viewing this topic.

Offline piper

  • nOOb
  • *
  • Posts: 23
  • Karma: 0
  • New Forum User
    • View Profile
  • Peppermint version(s): 4,5,6
SSD error
« on: August 29, 2015, 12:15:53 am »
My Satellite X205 has a 32GB ADATA SSD dedicated to PM6
It failed to boot past 'searching for btrfs' today, and after finding another thread with some help, I booted without 'splash quiet'  and found the complaint was about a fault in the / .
I pressed f as suggested and supposedly the repair was done and it rebooted successfully.
I think I had a few boot failures when using a Supertalent SSD on a previous install of PM5 on this machine, but successive boots sometimes worked.
The newer PM6 SSD setup requires less to do I think, from memory just setting the cron job for trim job was all that was suggested to do.
I need this machine to be reliable in portable locations, and would like to know any SSD setup or tests I can do.
Deleting quiet splash from grub would be helpful to speed recovery, but really I'm not used to HD errors, and it looks like a dodgy game to play.
Thanks for any suggestions.


Offline AndyInMokum

  • Global Moderator
  • Hero
  • *****
  • Posts: 4808
  • Karma: 1013
  • "Keep on Rockin' in the Free World"
    • View Profile
  • Peppermint version(s): PM 9 & PM 8 Respin-2 (64-bit)
Re: SSD error
« Reply #1 on: August 29, 2015, 01:01:48 am »
Hi piper, how's it going?  A few months ago, I was setting up a new Peppermint Six installation with a brand new Kingston 120GB SSDVinDSL turned me on to the following website, with SSD set up instructions.  One word describes it - SUPERBhttps://sites.google.com/site/easylinuxtipsproject/ssd.  After applying the tweaks, the SSD zips along and the machine runs effortlessly.   I highly recommend you bookmark this site  ;).

Edit:  If you're not using the btrfs file system.  I suggest you get rid of this pointless file search.  It'll save a little time on boot.
Code: [Select]
apt remove --purge btrfs-tools
« Last Edit: August 29, 2015, 01:09:57 am by AndyInMokum, Reason: Supplementary Information »
Backup! Backup! Backup! If you're missing any of these -  you ain't Backed Up!
For my system info please L/click HERE.

Offline piper

  • nOOb
  • *
  • Posts: 23
  • Karma: 0
  • New Forum User
    • View Profile
  • Peppermint version(s): 4,5,6
Re: SSD error
« Reply #2 on: August 29, 2015, 02:32:35 am »
Thanks for the link, the blurb I used suggested there was little to do, but things like noatime and swappiness weren't done to mention a few biggies.
I have removed the cron job for trim altogether and will only perform it manually now. I can do without the guessing of whats happening at boot time.
I've also removed the btrfs-tools, what is with the upstream people, people defaulting to having btrfs? Sounds like it is unsuitable for SSD and even less likely to be used if people migrate to SSD's.
Time will tell if I get a re-occurrence of errors.
I have a second ADATA 32GB and I'll look into a sync command for a periodic backup. I'll leave a more than 1GB of unused space next time. I guess I can resize the one I'm using to be larger also.

Offline AndyInMokum

  • Global Moderator
  • Hero
  • *****
  • Posts: 4808
  • Karma: 1013
  • "Keep on Rockin' in the Free World"
    • View Profile
  • Peppermint version(s): PM 9 & PM 8 Respin-2 (64-bit)
Re: SSD error
« Reply #3 on: August 29, 2015, 03:14:51 am »
Thanks for the link, the blurb I used suggested there was little to do, but things like noatime and swappiness weren't done to mention a few biggies.
I have removed the cron job for trim altogether and will only perform it manually now. I can do without the guessing of whats happening at boot time.
I've also removed the btrfs-tools, what is with the upstream people, people defaulting to having btrfs? Sounds like it is unsuitable for SSD and even less likely to be used if people migrate to SSD's.
Time will tell if I get a re-occurrence of errors.
I have a second ADATA 32GB and I'll look into a sync command for a periodic backup. I'll leave a more than 1GB of unused space next time. I guess I can resize the one I'm using to be larger also.
Yeah, it's a cracker of a webpage.  I enabled the trim at boot with the SSD I tweaked.  It works really well.  Any slowing was not even noticeable.  With the newer SSDs, leaving the 7% of unused space is not so relevant.  It's more of a precaution.  It's also still quite a large chunk of 32GB IMHO.  The noatime and dropping the swappiness to 1 really makes a difference.  Glad it's helping  ;).
Backup! Backup! Backup! If you're missing any of these -  you ain't Backed Up!
For my system info please L/click HERE.

Online PCNetSpec

  • Administrator
  • Hero
  • *****
  • Posts: 26051
  • Karma: 2839
  • "-rw-rw-rw-" .. The Number Of The Beast
    • View Profile
    • PCNetSpec
  • Peppermint version(s): Peppermint 10
Re: SSD error
« Reply #4 on: August 29, 2015, 09:19:06 am »
[EDIT]

Before doing this, check your SSD actually supports TRIM

Run:
Code: [Select]
sudo hdparm -I /dev/sda | grep "TRIM supported"
and if you get nothing returned your SSD does NOT support TRIM so stop now .. if it returns that your SSD does support TRIM, carry on below.

[END EDIT]

There *IS* a way to add fstrim to rc.local and still be able to check if it actually gets run at each boot.....

run:
Code: [Select]
sudo gedit /usr/bin/my-custom-trim
and make it read:-
Code: [Select]
#!/bin/sh
LOG=/var/log/trim.log
echo "*** $(date -R) ***" >> $LOG
fstrim -v / >> $LOG
#fstrim -v /home >> $LOG    ##uncomment this line if you have a separate /home partition
SAVE the file, and exit gedit.

back in the terminal make that executable with:
Code: [Select]
sudo chmod +x /usr/bin/my-custom-trim
now add that to rc.local so it runs each boot:
Code: [Select]
sudo gedit /etc/rc.local
and add the command to run my-cstom-trim above the "exit 0" line .. like this:
Code: [Select]
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

/usr/bin/my-custom-trim

exit 0
SAVE the file and exit gedit.

Now reboot.

Once you've rebooted, go to
Code: [Select]
gedit /var/log/trim.log
and you should see evidence that fstrim was run with a timestamp of when the reboot occurred.



There are plenty of online tutorial explaining what should be in your "my-custom-trim" script .. such as this one:
http://www.webupd8.org/2013/01/enable-trim-on-ssd-solid-state-drives.html
they add it to cron.daily .. but I obviously add it to a separate script, and run that script at each boot.
« Last Edit: August 29, 2015, 09:27:03 am by PCNetSpec »
WARNING: You are logged into reality as 'root' .. logging in as 'insane' is the only safe option.

Team Peppermint
PCNetSpec

Offline piper

  • nOOb
  • *
  • Posts: 23
  • Karma: 0
  • New Forum User
    • View Profile
  • Peppermint version(s): 4,5,6
Re: SSD error
« Reply #5 on: August 31, 2015, 12:03:15 am »
I checked the ADATA SSD  and it does have TRIM supported.  Your script could be worth implementing for my periodic manual trimming also, in case their is useful  information. One thing that springs to mind, is it might indicate that the trim was performed earlier than needed.
CF cards dont have TRIM support, though the manufactorers usually advertise some form of wear levelling.
I use another OS (RISC OS) that doesn't support TRIM  and only has PATA so I've taken notice. I think to use these (quite expensive) cards, I would strip the
casing off to let air circulate. I've seen CF cards get hot to touch when used in a camera.

Later Edit:
I have found the cause of the SSD corruption, by having it happen again.
When the laptop runs down on its battery, it just shuts down no matter what.
I have now changed the settings in the power management preferrences to shutdown when battery is critically low.
Cheers
« Last Edit: September 07, 2015, 11:39:09 pm by piper »