[sf-lug] New Toy, the $49 256G Sandisk SSD offered through the Kindle ads

[Ken Shaffer]

Amazon made a special offer through their Kindle ads -- $49 for the
Sandisk Ultra Plus 256G Solid State Disk (SSD).  I couldn't resist.

I had a $12 2.5" SATAIII USB3 enclosure, which I used for the SSD. The SSD
came with an empty gpt partition table.  Using gdisk, I entered the below
info and saved it.   The setup was for both UEFI and legacy, hence the 300M
EFI bootable and a 1M grub-bios flagged partition (for possible future
use).

Start at 2048 to align the disk.
Total 256G (238Gib) (G=10e9)
start            2048             4095        +1M    grub-bios
efi               4096          614399      +300M    boot
root1       614400      53043199     +25G
root2   53043200    105471999     +25G
Data  105472000    449404927    +163G
unallocated 25G
Total 512B sectors 34-500118158

calc allowed me to convert my rough sizes to sectors aligned to 1MB.  I
left approx 10% of the disk unallocated as some recommendations state on
these newer disks (older recommendations are to leave 20%).

The host machine for the install was a Toshiba Satellite S855-S5378, with
USB3 ports.  The host had Windows 8.1 and Two Ubuntu 14.04 installations
already present.  Secure boot was off.  The Ubuntu 64 bit 14.04 live media
on a memory stick plugged into a USB2 port booted, I plugged in the SSD and
started the installation.  The grub-bios partition was left "unused" to
avoid confusing the bootloader installation. The location for the
bootloader was by list selection, the only choices for the target  were sdc
or sdc3 (root), but no sdc2 choice for the EFI partition. The EFI partition
was tagged "efi", but the "format" button was gray and the partition could
not be formatted.  I selected the device sdc. As with all previous UEFI
installations to a USB target device, with a valid EFI partition on the
target, the bootloader installed to the internal hard disk's EFI partition,
messing up the grub.cfg file there, so the host would no longer boot.

The installation only took 6 minutes (I leave wireless off) and went
perfectly, other than the bootloader installtion.  The target would not
boot (it had no EFI bootloader installed).  The host would no longer boot,
it got the new bootloaders, and a new grub.cfg file requiring the USB.
This was easy enough to fix at the grub prompt, just set the root (may not
even be necessary) to  the hard disk partition, and pull in the grub.cfg
file from there with the configfile (hd0,gpt7)/boot/grub/grub.cfg command.
This brought up the grub menu, and allowed a successful boot.  I restored a
working grub.cfg  file on the host (I was expecting this, so I always keep
a spare copy around). Then mounted the USB3 target, and copied in the hard
disk's EFI file, changing the grub.cfg to the one from the installation.
The other glitch was in the target's fstab, which was mounting the hard
disk's EFI partition instead of the one on the SSD.
I applied several modifications I use on flash sticks to move frequently
written areas into ram, and successfully booted the target (in 20 seconds,
vs. 52 seconds for the internal hard disk).

Everything worked, video, and particularly wireless.  The boot was so fast,
I felt that I didn't even need to replace the Toshiba's hard disk with the
SSD. I ran my 1GB "dd copy" speed test, and pulled 185MB/sec off the root
partition. I ran update and pulled in 270M of packages.  Successfully
rebooted, and then ran into the only bad part -- fstrim failed to run.
fstrim is the manual way to free up blocks for the SSD which the filesystem
thinks have been deleted. Turns out this is a known problem with USB SSD
disks (well not known to me!). Whether it's UEFI Settings (BIOS), USB
controller, Ubuntu problems with certain chips, or the USB3 enclosure,
fstrim simply fails.  This probably will lead to speed degradation over
time, but if necessary, I'll just put the SSD into the internal SATA slot
to run fstrim. The SMART info indicated the SSD was SATAIII 6G capable,
running at 3G.

The SSD in the enclosure was put onto a USB2 port and booted in 26 seconds,
Still 1/2 the time of the internal hard disk.  The enclosure LED was
red instead of the blue it displays on a USB3 port.

The SSD was then moved to the internal slot of the Toshiba, and powered on.
 There was an error display, indicating a repair was needed, but ESC went
into the UEFI settings,which showed that the SSD was recognized. Exited
with no changes, and brought up the EFI boot menu with F12, whose HDD entry
offered Windows or Ubuntu.  Note that a second ubuntu entry (for shim) had
been deleted.  The Ubuntu (grubx64.efi) selection brought up the grub
screen.  Edited the hd1 to hd0 and used F10 to successfully boot.  Ran sudo
update-grub.  The SMART information indicated  that the SSD was now running
at 6G/sec.  A straight dd copy of the root partition to null of 1G ran at
525MB/sec. (the rated speed I believe, which surprised me). The Kingston
60G SSD which I had installed to my old 32 bit HP laptop gave only
125MB/seconds in the same test (although its rating was at least 80% of the
Sandisk's. Update worked normally.  fstrim worked normally. Trying boot
again resulted in the same error screen. Forcing the EFI boot menu (F12)
worked, but with the manual intervention necessary, the boot speed was 26
seconds, a little slower than the 20 seconds previously seen on the USB3
enclosure (and the 21 seconds seen after updates).

I replaced the Toshiba's internal hard disk, the EFI boot choices remained
at only Windows or ubuntu (grub), which was fine since secure boot is off.
Still, it's a cautionary note to be aware of the unwanted changes which
take place on UEFI host machines installing to USB devices.  The SSD will
live in the USB3 enclosure for now, and I'll see how/if it's speed degrades
without running fstrim.
 Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20140605/1f07a5c6/attachment.html>