Optimizing Linux Systems For Solid State Disks 207
tytso writes "I've recently started exploring ways of configuring Solid State Disks (SSDs) so they work most efficiently in Linux. In particular, Intel's new 80GB X25-M, which has fallen down to a street price of around $400 and thus within my toy budget. It turns out that the Linux Storage Stack isn't set up well to align partitions and filesystems for use with SSD's, RAID systems, and 4k sector disks. There are also some interesting configuration and tuning that we need to do to avoid potential fragmentation problems with the current generation of Intel SSDs. I've figured out ways of addressing some of these issues, but it's clear that more work is needed to make this easy for mere mortals to efficiently use next generation storage devices with Linux."
Mere mortals need mroe toy budget (Score:5, Insightful)
Re:Mere mortals need mroe toy budget (Score:2, Insightful)
Re:SSD's should have no problem with fragmentation (Score:4, Insightful)
From economics, lets turn our attention to optimizing this toy of ours. The thing with SSDs is that they don't have a read/write head to worry about. This means that no matter where the data is stored in the device, all we need to do is specify the fetch location and the logic circuits select that block to extract the data from desired location. From what I've heard, the SSDs have an algorithm to actually assign different blocks to store the data so that the memory cells in a single locations aren't overused.
Why pretend these are ordinary disks? (Score:5, Insightful)
SSDs gradually gain more and more sophisticated controllers which do more and more to try to make the SSD seem like an ordinary hard drive, but at the end of the day the differences are great enough that they can't all be plastered over that way (the fragmentation/long term use problems the story linked to are a good example). I know that (at present- this could and should be fixed) making these things run on a regular hard drive interface and tolerate being used with a regular FS is important for Windows compatibility, but it seems like a lot of cost could be avoided and a lot of performance gained by having a more direct flash interface and using flash-specific filesystems like UBIFS, YAFFS2, or LogFS. I have to wonder why vendors aren't pursuing that path.
Re:Agreed .. But equally important is ... (Score:4, Insightful)
Re:Is it only linux? (Score:5, Insightful)
Yeah, hard disk manufacturers.
Since they moved to large disks which require LBA, they've been fudging the CHS values returned by the drive to get the maximum size available to legacy operating systems. Since when did a disk have 63 heads? Never. It doesn't even make sense anymore when most hard disks are single platter (therefore having 1 or 2) and SSDs don't even have heads.
What they need to do is define a new command structure for accurately determining the best structure on the disk - on an SSD this would report the erase block size or so, on a hard disk, how many sectors are in a cylinder, without fucking around with some legacy value designed in the 1980's.
Another file strategy - file segregation by f(x) (Score:5, Insightful)
Why not functionally group files to decrease or eliminate fragmentation? Or maybe this is already done.
For example - I have a large collection of MP3 files. They essentially do not change, as in I don't edit them, and rarely erase them. The file system could look at they type of file (mp3, vs doc) and place it accordingly. It could also look at the last change in the file and place it in a certain area. Older unchanged files are placed in a tightly placed/packed file area that is optimized and not fragmented.
Re:Mere mortals need mroe toy budget (Score:1, Insightful)
Well maybe you should check who the story submitter is. :-)
If he doesn't "have the time to optimize it", we're in deep trouble
Thinkpad X300 came with defrag tools (Score:3, Insightful)
I purchased an X300 Thinkpad for the company this week and took a close look at it. I thought expensive business notebooks come without crapware. And I was sure the X300 would be optimized. But they had defrags scheduled! I always thought defrag is a no no for ssds. Now I am not sure anymore. I deinstalled it first. But who knows?
Re:One True File System (Score:2, Insightful)
Although the technology it is used in is repugnant, NTFS has always been the One True Filesystem.
I thought ZFS was.
And ZFS has native support for SSD as L2ARC. http://www.c0t0d0s0.org/media/presentations/ssd.pdf [c0t0d0s0.org] I have nothing but praise for ZFS. Simple to manage, reliable, fast. With native CIFS instead of User file system Samba, I've seen orders of magnitude performance from windows machines when doing networked file access. Gary
Re:Still too expensive... (Score:3, Insightful)
The modern hot-shit high-speed CF cards have wear leveling and do UDMA transfers, you get a CF to ATA adapter, not CF to USB, and they will outperform most hard disks.
Re:Don't SSD's have a pre-set number of writes? (Score:2, Insightful)
Re:Why pretend these are ordinary disks? (Score:3, Insightful)
Why is the Linux block subsystem still stuck in the 20MB hard-disk era like this?
As one who had to tune the performance of hard drives at the kernel level, I can say with some authority that the Linux block subsystem is not at all stuck in the 20MB hard-disk era. In fact, everything is logical blocks these days, and it's the filesystem driver and IO schedulers which determine the write sequences. The block layer is largely "dumb" in this regard, and treats every block device as nothing more than a large array of blocks. A properly designed wear-leveling filesystem has no dependencies on the underlying hardware with one exception: block size. But seeing as every Linux filesystem since Ext2 has had the option of creating filesystems with different block sizes, I doubt this is, or ever will be, an issue.
The only real issue with wear-leveling filesystems is that they don't work well with conventional hard disks, largely due to the fact that with flash, the block access time is pretty much constant no matter where on the drive it is located. Hence, there's no need to schedule based on C/H/S values. Because of this disparity, there won't be ONE TRUE FILESYSTEM in Linux. This might actually be a good thing, if you've ever been privy to the debates over Reiserfs and Ext3...
The hardware SSD wear-levelling algorithms used by Intel, et al... are nothing special. Yes, they probably do offer higher performance than a general purpose filesystem, but performance is not their reason for existence. They exist largely because the overwhelming majority of consumer devices still use FAT32, which would destroy an SSD without wear-leveling very quickly. Think of how many flash chips are used in cameras, cellphones, thumb drives, etc... Intel had to do this just to access the non-Linux market.