Migrating from hdd to ssd drive
Hi everyone, Today I updated my laptop to use an ssd drive. I am using a Samsung 830 series (128 Gb) drive. I've got most things working nicely, but I had a few questions that others who have already done this may be able to assist with: 1. Hibernate has seemed to stop working for me ever since I installed the ssd. I'm fairly sure it worked with the old hard drive, but now if I pm-hibernate, and turn back on the machine, it is just equivalent of shutting down and booting. i.e. my session is not resumed, and I am asked to log in. I have a swap partition, output of free -m is: daniel@Vostro-3350:/tmp$ free -m total used free shared buffers cached Mem: 3947 659 3287 0 35 346 -/+ buffers/cache: 278 3669 Swap: 6143 0 6143 2. What tweaks do people use to prolong ssd life and also improve performance? Currently I have an fstab which looks like this: # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sda2 during installation UUID=ed09c67d-bd34-42be-8f3b-3dfb567ea764 / ext4 errors=remount-ro,discard,noatime 0 0 UUID=9db7ef9e-5298-4400-8b26-cdf9d6ec4168 /home ext4 defaults,discard,noatime 0 0 # swap was on /dev/sda6 during installation UUID=3df92924-3bd3-4292-a635-a78e9e36d9c8 none swap sw 0 0 tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0 (obviously partition table has changed a bit since I moved from a dual booting system on the hdd to just ubuntu on ssd) I've also made a symbolic link from /var/log to /tmp/ which should apparently help reduce writing to the ssd. (apparently the last line of the fstab means /tmp is stored in ram) I've also added this in /etc/default/grub, and ran update-grub: GRUB_CMDLINE_LINUX="elevator=noop" Is there anything else I should do? 3. My last question: I here alignment is important to ensure best performance and again help prolong the life of the ssd.
From what I read using a multiple of 512 for the first block can achieve this. I attempted to do this with fdisk, but to be honest, was not quite sure what I was doing. (I actually just cp -ax /from/hdd* /to/path/ssd for my ubuntu installation, so didn't use the ubuntu install cd to install on the ssd. (so obviously created all partitions manually). Here is my fdisk output: daniel@Vostro-3350:/tmp$ sudo fdisk -l /dev/sda
Disk /dev/sda: 128.0 GB, 128035676160 bytes 255 heads, 63 sectors/track, 15566 cylinders, total 250069680 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x3f5f6184 Device Boot Start End Blocks Id System /dev/sda1 * 2048 31459327 15728640 83 Linux /dev/sda2 31459328 44042239 6291456 83 Linux /dev/sda3 44042240 250069679 103013720 83 Linux Are these partitions aligned? If not how can I repair this, (hopefully not by re-installing!) I'm running ubuntu 12.10 as well. Thanks in advance for any help, Dan
On Sat, Dec 15, 2012 at 3:43 PM, Daniel Dalton <d.dalton@iinet.net.au> wrote:
2. What tweaks do people use to prolong ssd life and also improve performance?
Leave 20% of the disk as unpartitioned, spare area, it will greatly help performance and consistency of I/O. http://www.anandtech.com/show/6489/playing-with-op Cheers -- Aryan Ameri
On Sat, 15 Dec 2012, Aryan Ameri <info@ameri.me> wrote:
On Sat, Dec 15, 2012 at 3:43 PM, Daniel Dalton <d.dalton@iinet.net.au> wrote:
2. What tweaks do people use to prolong ssd life and also improve performance?
Leave 20% of the disk as unpartitioned, spare area, it will greatly help performance and consistency of I/O.
The article you cited stated that the use of TRIM combined with spare space in the filesystem should give all the benefits of having unpartitioned space. The graph part made no sense to a skim read so I'm not sure what they are on about with that. I guess that the real issue is to just not fill your storage and make sure TRIM is working. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Sat, Dec 15, 2012 at 10:28 PM, Russell Coker <russell@coker.com.au> wrote:
On Sat, 15 Dec 2012, Aryan Ameri <info@ameri.me> wrote:
On Sat, Dec 15, 2012 at 3:43 PM, Daniel Dalton <d.dalton@iinet.net.au> wrote:
2. What tweaks do people use to prolong ssd life and also improve performance?
Leave 20% of the disk as unpartitioned, spare area, it will greatly help performance and consistency of I/O.
The article you cited stated that the use of TRIM combined with spare space in the filesystem should give all the benefits of having unpartitioned space.
Yes that is true, if the OS supports TRIM, just leaving about 20% unused should provide the same results. However I have found TRIM support on linux to be a bit spotty, depending on the distribution, kernel, filesystem, etc.
The graph part made no sense to a skim read so I'm not sure what they are on about with that.
Really?! I thought the graphs are very clear.
I guess that the real issue is to just not fill your storage and make sure TRIM is working.
This is certainly true. Making sure TRIM is working is the single best thing you can do with a SSD. Also make sure your filesystem is not doing some sort of re-ordering/defragmenting is vital. As for life expectancy, the Sammy 830 is a very good SSD with very intelligent firmware. It should easily last you a good 5 years even if you are writing 100GB every single day to it. Unless you are doing video production or something of that nature on the machine, I would say don't worry about it. Cheers -- Aryan
On Sat, 15 Dec 2012, Aryan Ameri <info@ameri.me> wrote:
Yes that is true, if the OS supports TRIM, just leaving about 20% unused should provide the same results. However I have found TRIM support on linux to be a bit spotty, depending on the distribution, kernel, filesystem, etc.
I've just had very poor performance on BTRFS filesystems mounted with the "discard" option using a 120G Intel SSD known as "INTEL SSDSC2CT12 300i". Turning off the discard option at the suggestion of a member of the BTRFS list improved performance by more than a factor of 8! Apparently the problem is that TRIM is a non-queuing command so it blocks everything else. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On 16/12/12 22:34, Russell Coker wrote:
Apparently the problem is that TRIM is a non-queuing command so it blocks everything else.
Yup, this is what I've been banging on about for years now whenever people start talking about how good this should be, see this 2009 LWN article "The trouble with discard" here: http://lwn.net/Articles/347511/ However, SATA 3.1 finally introduced a queued TRIM command: http://techreport.com/news/21311/sata-3-1-spec-brings-swap-standard-improved... cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
Chris Samuel <chris@csamuel.org> wrote:
However, SATA 3.1 finally introduced a queued TRIM command:
http://techreport.com/news/21311/sata-3-1-spec-brings-swap-standard-improved...
Thus SATA 3.1 or later should be on my "desirable features" list for the next laptop or desktop system that I purchase. That's useful to know. My current laptop has SATA, but I think it's old enough to predate SATA 3, hence wouldn't benefit from the full performance of an SSD.
On Sat, Dec 15, 2012 at 05:17:01PM +1100, Aryan Ameri wrote:
On Sat, Dec 15, 2012 at 3:43 PM, Daniel Dalton <d.dalton@iinet.net.au> wrote:
2. What tweaks do people use to prolong ssd life and also improve performance?
Leave 20% of the disk as unpartitioned, spare area, it will greatly help performance and consistency of I/O.
Hmm, something to think about. I'm not so sure though. The manufacturer leaves some of the space as unusable, but I know this isn't 20%. Also per gb it is quite expensive, so I'd really hope the performance increase is significant enough. I'll investigate further - thanks for the idea. Cheers, Dan
Daniel Dalton <d.dalton@iinet.net.au> writes:
I've also made a symbolic link from /var/log to /tmp/ which should apparently help reduce writing to the ssd. (apparently the last line of the fstab means /tmp is stored in ram)
apt-get install busybox-syslogd is better IMO. It simply stores logs in a ring buffer in RAM. Default size is aimed at embedded, so recommend increase in /etc/default/busybox-syslogd. Read with "logread"; monitor with "logread -f". I assume you're using swap only so you can suspend-to-disk. If so, set vm.swappiness to 0 if you want to avoid bonus writes to the SSD -- although I suspect that kind of ricing may no longer be worthhile due to advances in FTL firmware.
3. My last question: I here alignment is important to ensure best performance and again help prolong the life of the ssd. From what I read using a multiple of 512 for the first block can achieve this.
parted's --align=optimal ought to help, but I'm no expert.
On Sat, Dec 15, 2012 at 08:27:07PM +1100, Trent W. Buck wrote:
apparently help reduce writing to the ssd. (apparently the last line of the fstab means /tmp is stored in ram)
apt-get install busybox-syslogd is better IMO. It simply stores logs in a ring buffer in RAM. Default size is aimed at embedded, so recommend increase in /etc/default/busybox-syslogd. Read with "logread"; monitor with "logread -f".
Hmm, ok, I'll do that.
I assume you're using swap only so you can suspend-to-disk. If so, set vm.swappiness to 0 if you want to avoid bonus writes to the SSD --
Yes, good idea, I just thought of that after my first email, thanks.
although I suspect that kind of ricing may no longer be worthhile due to advances in FTL firmware.
Hopefully
3. My last question: I here alignment is important to ensure best performance and again help prolong the life of the ssd. From what I read using a multiple of 512 for the first block can achieve this.
parted's --align=optimal ought to help, but I'm no expert.
I'll certainly investigate, thanks.
participants (6)
-
Aryan Ameri -
Chris Samuel -
Daniel Dalton -
Jason White -
Russell Coker -
trentbuck＠gmail.com