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

[Dan Murphy]

Minor point. I think I made a mistake.

You said:

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%).

I left 20% (yes, and older SSD) UNUSED. Can you or someone verify if
you should leave xx% un used or un allocated?


On Thu, Jun 5, 2014 at 4:15 PM, Ken Shaffer <kenshaffer80 at gmail.com> wrote:
> 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
>
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/