Hi
I was wondering what the state of SSD support was. I upgraded a netbook with a SSD and took the defaults from F14's live installable USB disk's Anaconda.
The SSD comes unformatted, it's a OCZ Vertex 2E (SATA II) which apparently has TRIM capability.
I wondered how I can tell if this hardware is being used to its full potential, if the TRIM capability is being used and if the partitions are aligned as they ought to be.
The output of sfdisk -l doesn't make it obvious if the disk is using 4k sectors or is aligned in any particular way. Googling reveals lots of conflicting information... so any ideas?
-Cam
PS. output of sfdisk -l:
[root@newt ~]# sfdisk -l
Disk /dev/sda: 7297 cylinders, 255 heads, 63 sectors/track Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System /dev/sda1 * 0+ 63- 64- 512000 83 Linux /dev/sda2 63+ 7297- 7234- 58101760 8e Linux LVM /dev/sda3 0 - 0 0 0 Empty /dev/sda4 0 - 0 0 0 Empty
Disk /dev/dm-0: 3500 cylinders, 255 heads, 63 sectors/track
sfdisk: ERROR: sector 0 does not have an msdos signature /dev/dm-0: unrecognized partition table type No partitions found
Disk /dev/dm-1: 611 cylinders, 255 heads, 63 sectors/track
sfdisk: ERROR: sector 0 does not have an msdos signature /dev/dm-1: unrecognized partition table type No partitions found
Disk /dev/dm-2: 3120 cylinders, 255 heads, 63 sectors/track
sfdisk: ERROR: sector 0 does not have an msdos signature /dev/dm-2: unrecognized partition table type No partitions found
Camilo Mesias wrote:
The output of sfdisk -l doesn't make it obvious if the disk is using 4k sectors or is aligned in any particular way.
[...]
Disk /dev/sda: 7297 cylinders, 255 heads, 63 sectors/track Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System /dev/sda1 * 0+ 63- 64- 512000 83 Linux /dev/sda2 63+ 7297- 7234- 58101760 8e Linux LVM /dev/sda3 0 - 0 0 0 Empty /dev/sda4 0 - 0 0 0 Empty
IMHO it makes obvious that it is extremely bad aligned. C/H/S are all odd numbers (that is, not even). The important partition (sda2) starts at 63, which is off alignment.
I don't know if your drive is one of the "let's shift every sector by one to make MSDOS..WINXP aligned". If the SSD is not doing tricks, this layout is misaligned.
I partitioned my SSD in the following way. I forced 56 as sector/track (which is dividable by 8, 4096/512), so all partitions should come out 4KiB aligned. (used both CHS and sector output for clarity)
No guarantee that my approach is right and that your SSD is wrong. :-)
# fdisk -l /dev/sda
Disk /dev/sda: 256.0 GB, 256060514304 bytes 54 heads, 56 sectors/track, 165383 cylinders Units = cylinders of 3024 * 512 = 1548288 bytes Disk identifier: 0x180397b2
Device Boot Start End Blocks Id System /dev/sda1 * 1 1 1484 83 Linux /dev/sda2 2 165383 250057584 5 Extended /dev/sda5 2 476 718172 83 Linux /dev/sda6 477 38620 57673700 83 Linux /dev/sda7 38621 42782 6292916 82 Linux swap / Solaris /dev/sda8 42783 98263 83887244 83 Linux /dev/sda9 98264 165383 101485412 83 Linux
# fdisk -l -u /dev/sda
Disk /dev/sda: 256.0 GB, 256060514304 bytes 54 heads, 56 sectors/track, 165383 cylinders, total 500118192 sectors Units = sectors of 1 * 512 = 512 bytes Disk identifier: 0x180397b2
Device Boot Start End Blocks Id System /dev/sda1 * 56 3023 1484 83 Linux /dev/sda2 3024 500118191 250057584 5 Extended /dev/sda5 3080 1439423 718172 83 Linux /dev/sda6 1439480 116786879 57673700 83 Linux /dev/sda7 116786936 129372767 6292916 82 Linux swap / Solaris /dev/sda8 129372824 297147311 83887244 83 Linux /dev/sda9 297147368 500118191 101485412 83 Linux
On Sun, Dec 26, 2010 at 3:56 PM, Roberto Ragusa mail@robertoragusa.it wrote:
Camilo Mesias wrote:
The output of sfdisk -l doesn't make it obvious if the disk is using 4k sectors or is aligned in any particular way.
[...]
Disk /dev/sda: 7297 cylinders, 255 heads, 63 sectors/track Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System /dev/sda1 * 0+ 63- 64- 512000 83 Linux /dev/sda2 63+ 7297- 7234- 58101760 8e Linux LVM
You don't want to use LVM (and you should mount the fs with the discard option for trim to work).
Hi,
On Sun, Dec 26, 2010 at 10:32 AM, drago01 drago01@gmail.com wrote:
You don't want to use LVM (and you should mount the fs with the discard option for trim to work).
At plumbers it came out during the filesystem talk that the discard option is a really bad idea. It apparently has performance and reliabilty problems. Apparently, you're just supposed to run a command manually (that I don't remember of hand) when your disk starts to fill up.
--Ray
On Sun, Dec 26, 2010 at 6:34 PM, Ray Strode halfline@gmail.com wrote:
Hi,
On Sun, Dec 26, 2010 at 10:32 AM, drago01 drago01@gmail.com wrote:
You don't want to use LVM (and you should mount the fs with the discard option for trim to work).
At plumbers it came out during the filesystem talk that the discard option is a really bad idea. It apparently has performance and reliabilty problems. Apparently, you're just supposed to run a command manually (that I don't remember of hand) when your disk starts to fill up.
Yeah this depends on the drive though (on my Samsung drive it does not seem to have a noticeable performance hit).
The tool that can be run from time to time is the "wiper.sh" script found in the hdparm tarball.
On 26/12/10 18:42, drago01 wrote:
On Sun, Dec 26, 2010 at 6:34 PM, Ray Strodehalfline@gmail.com wrote:
Hi,
On Sun, Dec 26, 2010 at 10:32 AM, drago01drago01@gmail.com wrote:
You don't want to use LVM (and you should mount the fs with the discard option for trim to work).
At plumbers it came out during the filesystem talk that the discard option is a really bad idea. It apparently has performance and reliabilty problems. Apparently, you're just supposed to run a command manually (that I don't remember of hand) when your disk starts to fill up.
Yeah this depends on the drive though (on my Samsung drive it does not seem to have a noticeable performance hit).
The tool that can be run from time to time is the "wiper.sh" script found in the hdparm tarball.
Manually running a script "from time to time"? Can't we run this automatically instead? Why doesn't the drive do this?
On 12/26/2010 01:53 PM, nodata wrote:
On 26/12/10 18:42, drago01 wrote:
On Sun, Dec 26, 2010 at 6:34 PM, Ray Strodehalfline@gmail.com wrote:
Hi,
On Sun, Dec 26, 2010 at 10:32 AM, drago01drago01@gmail.com wrote:
You don't want to use LVM (and you should mount the fs with the discard option for trim to work).
At plumbers it came out during the filesystem talk that the discard option is a really bad idea. It apparently has performance and reliabilty problems. Apparently, you're just supposed to run a command manually (that I don't remember of hand) when your disk starts to fill up.
Yeah this depends on the drive though (on my Samsung drive it does not seem to have a noticeable performance hit).
The tool that can be run from time to time is the "wiper.sh" script found in the hdparm tarball.
Manually running a script "from time to time"? Can't we run this automatically instead? Why doesn't the drive do this?
The drive must first be informed of what sectors are empty or occupied, because from the TRADITIONAL hard drive's perspective, all sectors are always occupied by data. TRIM/DISCARD command has changed this, by creating a method of telling the hard drive what sectors are empty.
Only the filesystem knows which sectors are empty or occupied, so your choice is
(a) inform drive of empty sectors, each time a file is deleted
(b) periodically (once a day or week or month, etc.), inform drive of empty sectors that have appeared since last check.
Option (a) apparently slows down file deletion noticeably, and potentially "erases" sectors that will be immediately re-filled with useful data (== extra, unnecessary work).
That leaves option (b).
Jeff
On 12/26/2010 02:08 PM, Jeff Garzik wrote:
On 12/26/2010 01:53 PM, nodata wrote:
On 26/12/10 18:42, drago01 wrote:
On Sun, Dec 26, 2010 at 6:34 PM, Ray Strodehalfline@gmail.com wrote:
Hi,
On Sun, Dec 26, 2010 at 10:32 AM, drago01drago01@gmail.com wrote:
You don't want to use LVM (and you should mount the fs with the discard option for trim to work).
At plumbers it came out during the filesystem talk that the discard option is a really bad idea. It apparently has performance and reliabilty problems. Apparently, you're just supposed to run a command manually (that I don't remember of hand) when your disk starts to fill up.
Yeah this depends on the drive though (on my Samsung drive it does not seem to have a noticeable performance hit).
The tool that can be run from time to time is the "wiper.sh" script found in the hdparm tarball.
Manually running a script "from time to time"? Can't we run this automatically instead? Why doesn't the drive do this?
The drive must first be informed of what sectors are empty or occupied, because from the TRADITIONAL hard drive's perspective, all sectors are always occupied by data. TRIM/DISCARD command has changed this, by creating a method of telling the hard drive what sectors are empty.
Only the filesystem knows which sectors are empty or occupied, so your choice is
(a) inform drive of empty sectors, each time a file is deleted
(b) periodically (once a day or week or month, etc.), inform drive of empty sectors that have appeared since last check.
Option (a) apparently slows down file deletion noticeably, and potentially "erases" sectors that will be immediately re-filled with useful data (== extra, unnecessary work).
That leaves option (b).
Jeff
Various drives perform better or worse with file system, fine grained discard support so not all will see a performance hit.
Ric
I'm confused now about what Anaconda has done. I checked with the commands from this site:
http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase...
And starting fdisk with different arguments gives more sensible looking results. Note that I haven't changed the on-disk structures at this point.
[root@newt ~]# fdisk -H 224 -S 56 /dev/sda
Command (m for help): p
Disk /dev/sda: 60.0 GB, 60022480896 bytes 224 heads, 56 sectors/track, 9345 cylinders, total 117231408 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: 0x000e2854
Device Boot Start End Blocks Id System /dev/sda1 * 2048 1026047 512000 83 Linux /dev/sda2 1026048 117229567 58101760 8e Linux LVM
Since C/H/S are a fiction, does this mean that the layout chosen by Anaconda is actually OK?
Also I ran a command against the PV:
[root@newt ~]# pvs /dev/sda2 -o+pe_start PV VG Fmt Attr PSize PFree 1st PE /dev/sda2 vg_newt lvm2 a- 55.41g 0 1.00m
This also seems to suggest the 1st PE is reasonably aligned.
Can anyone explain if I have misunderstood these commands?
Next I checked for other tweaks that might be of use and found:
http://www.zdnet.com/blog/perlow/geek-sheet-a-tweakers-guide-to-solid-state-...
I changed the elevator to noop in /etc/rc.local and set noatime and discard in /etc/fstab.
-Cam
On Mon, Dec 27, 2010 at 01:06:21AM +0000, Camilo Mesias wrote:
I'm confused now about what Anaconda has done. I checked with the commands from this site:
http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase...
Anaconda (really parted) defaults to sane aligment now:
http://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Gu...
Ric Wheeler rwheeler@redhat.com writes:
[...] Various drives perform better or worse with file system, fine grained discard support so not all will see a performance hit.
Could the system run benchmarks to determine whether its own drives fall into this category?
- FChE
On Mon, Dec 27, 2010 at 2:34 PM, Frank Ch. Eigler fche@redhat.com wrote:
Ric Wheeler rwheeler@redhat.com writes:
[...] Various drives perform better or worse with file system, fine grained discard support so not all will see a performance hit.
Could the system run benchmarks to determine whether its own drives fall into this category?
The proper solution is to batch them and don't send a discard for every operation. There has been work being done in this direction not sure what the outcome was.
Frank Ch. Eigler wrote:
Could the system run benchmarks to determine whether its own drives fall into this category?
http://sourceforge.net/projects/test-discard/
Made by Red Hat.
The important thing to note: the FUD about discard and claims of poor performance are against engineering sample SSDs - not retail SSDs. My retail Intel G2 SSDs have no issues with discard.
On 12/27/2010 09:55 AM, Michael Cronenworth wrote:
Frank Ch. Eigler wrote:
Could the system run benchmarks to determine whether its own drives fall into this category?
http://sourceforge.net/projects/test-discard/
Made by Red Hat.
The important thing to note: the FUD about discard and claims of poor performance are against engineering sample SSDs - not retail SSDs. My retail Intel G2 SSDs have no issues with discard.
Hi Michael,
The testing we have done on recent kernels does show a wide variance in performance across *shipping* drives, not just samples.
That is why we default discard to "off" in upstream kernels still :)
Ric
devel@lists.stg.fedoraproject.org
-
Camilo Mesias -
Chuck Anderson -
drago01 -
Frank Ch. Eigler -
Jeff Garzik -
Michael Cronenworth -
nodata -
Ray Strode -
Ric Wheeler -
Roberto Ragusa