Comments on: Should Filesystems Be Optimized for SSD’s? http://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-for-ssds/ Musings about Open Source, Linux, and Life by Theodore Tso Mon, 22 Feb 2010 22:39:59 -0500 http://wordpress.org/?v=2.8.6 hourly 1 By: Thomas http://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-for-ssds/comment-page-1/#comment-3054 Thomas Sat, 13 Feb 2010 21:06:02 +0000 http://thunk.org/tytso/blog/?p=281#comment-3054 I personally expect SSDs to become dumb in the future, as soon as they stop being pricey products made in USA and start being mass products made in China. The manufacturers will start putting the necessary "intelligence" into a windows driver (for almost no cost per unit) instead of into costly on-device silicon. At least, this is what happened to other devices: WLAN controllers (cf. early Prism chips with the ones used today), Laser printers (GDI), you name it. I personally expect SSDs to become dumb in the future, as soon as they stop being pricey products made in USA and start being mass products made in China. The manufacturers will start putting the necessary “intelligence” into a windows driver (for almost no cost per unit) instead of into costly on-device silicon. At least, this is what happened to other devices: WLAN controllers (cf. early Prism chips with the ones used today), Laser printers (GDI), you name it.

]]> By: Mark http://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-for-ssds/comment-page-1/#comment-2790 Mark Sat, 14 Nov 2009 03:32:01 +0000 http://thunk.org/tytso/blog/?p=281#comment-2790 > And if Intel never releases a firmware update to add ATA TRIM support, then > I will be out $400 out of my own pocket for an SSD that lacks this capability, > and so adding a block allocator which works around limitations of the X25-M > probably makes sense. If it turns out that it takes two years before disks > that have ATA TRIM support show up, then it will definitely make sense to > add such an optimization. (Hard drive vendors have been historically > S-L-O-W to finish standardizing new features and then letting such features > enter the market place, so I’m not necessarily holding my breath; after all, > the Linux block device layer and and file systems have been ready to send > ATA TRIM support for about six months; what’s taking the ATA committees > and SSD vendors so long? Is this indeed working with TRIM enabled SSD's today? I read somewhere in the OCZ forums, in a post by the hdparm author, that issues showed up when running on real hardware, causing it to be disabled for now. > On the other hand, if Intel releases ATA TRIM support next month, then it > might not be worth my effort to add such a mount option to ext4. So, Ted, will we see such optimization now that Intel has officially left its early adopters out in the cold? Also, how much of this as well as your previous posts on the subject also applies to USB thumb drives? Any (pun not intended) thumb rules to follow? But hey, Kingston is now shipping 40 GB SSD's with Intel 2-gen internals for around $100 or so. Not shipping with TRIM support but a new firmware is in the works. Getting mine on monday :-) > And if Intel never releases a firmware update to add ATA TRIM support, then
> I will be out $400 out of my own pocket for an SSD that lacks this capability,
> and so adding a block allocator which works around limitations of the X25-M
> probably makes sense. If it turns out that it takes two years before disks
> that have ATA TRIM support show up, then it will definitely make sense to
> add such an optimization. (Hard drive vendors have been historically
> S-L-O-W to finish standardizing new features and then letting such features
> enter the market place, so I’m not necessarily holding my breath; after all,
> the Linux block device layer and and file systems have been ready to send
> ATA TRIM support for about six months; what’s taking the ATA committees
> and SSD vendors so long?

Is this indeed working with TRIM enabled SSD’s today? I read somewhere in the OCZ forums, in a post by the hdparm author, that issues showed up when running on real hardware, causing it to be disabled for now.

> On the other hand, if Intel releases ATA TRIM support next month, then it
> might not be worth my effort to add such a mount option to ext4.

So, Ted, will we see such optimization now that Intel has officially left its early adopters out in the cold?

Also, how much of this as well as your previous posts on the subject also applies to USB thumb drives? Any (pun not intended) thumb rules to follow?

But hey, Kingston is now shipping 40 GB SSD’s with Intel 2-gen internals for around $100 or so. Not shipping with TRIM support but a new firmware is in the works. Getting mine on monday :-)

]]> By: Alan Brown http://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-for-ssds/comment-page-1/#comment-2768 Alan Brown Wed, 28 Oct 2009 14:14:29 +0000 http://thunk.org/tytso/blog/?p=281#comment-2768 Intel just added TRIM to the latest firmware update for X25-M drives. The update won't work on the earliest drives :-( Formy planned use (Backup spooling) kernel TRIM support would be a huge win as the files I'm working with are approx 10Gb apiece. Intel just added TRIM to the latest firmware update for X25-M drives.

The update won’t work on the earliest drives :-(

Formy planned use (Backup spooling) kernel TRIM support would be a huge win as the files I’m working with are approx 10Gb apiece.

]]> By: John and Dagny Galt http://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-for-ssds/comment-page-1/#comment-2756 John and Dagny Galt Sun, 25 Oct 2009 11:56:14 +0000 http://thunk.org/tytso/blog/?p=281#comment-2756 Additional mathmatics for the more challenged amongst us. http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device . Additional mathmatics for the more challenged amongst us.

http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device

.

]]> By: martin0641 http://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-for-ssds/comment-page-1/#comment-2725 martin0641 Tue, 06 Oct 2009 15:20:25 +0000 http://thunk.org/tytso/blog/?p=281#comment-2725 I'd like to know how the TRIM command will be passed through RAID controllers, such as the Intel Matrix many people use. I have 2 160GB Gen2 Intel X25-M's and I've been trying to figure out the best way to stripe and subsequently format them for a dual boot Windows 7 / Linux Mint system. People seem to be testing using low level tools and saying 128K stripe sizes are best because that is the Intel native size, but it's been hard finding guidance on what block size to use for the filesystem itself. My first reaction would be to say a 256K block size would split the data evenly, but that seems terribly wasteful on devices with such limited capacity. Does anyone have any ideas, for regular desktop usage, games, and dual booting from an Intel Matrix setup, what a suggested stripe/filesystem size would be? One possibly for maximum speed, and another for a reasonable speed/space comprimise? I’d like to know how the TRIM command will be passed through RAID controllers, such as the Intel Matrix many people use.

I have 2 160GB Gen2 Intel X25-M’s and I’ve been trying to figure out the best way to stripe and subsequently format them for a dual boot Windows 7 / Linux Mint system.

People seem to be testing using low level tools and saying 128K stripe sizes are best because that is the Intel native size, but it’s been hard finding guidance on what block size to use for the filesystem itself.

My first reaction would be to say a 256K block size would split the data evenly, but that seems terribly wasteful on devices with such limited capacity.

Does anyone have any ideas, for regular desktop usage, games, and dual booting from an Intel Matrix setup, what a suggested stripe/filesystem size would be? One possibly for maximum speed, and another for a reasonable speed/space comprimise?

]]> By: antiram http://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-for-ssds/comment-page-1/#comment-2697 antiram Mon, 17 Aug 2009 20:04:09 +0000 http://thunk.org/tytso/blog/?p=281#comment-2697 TRIM works on Indilinx controllers with firmware 1711. Current linux solution is a wiper tool: http://www.ocztechnologyforum.com/forum/showthread.php?t=60882 TRIM works on Indilinx controllers with firmware 1711.
Current linux solution is a wiper tool:
http://www.ocztechnologyforum.com/forum/showthread.php?t=60882

]]> By: Hannu http://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-for-ssds/comment-page-1/#comment-2694 Hannu Sun, 16 Aug 2009 13:11:25 +0000 http://thunk.org/tytso/blog/?p=281#comment-2694 Hi! While waiting for the TRIM option, would it be of any use to fill the deleted sectors with 0xFF? Would the SSD consider it as erased or not? Easy to try; when the disk is getting slower, just fill all free space with a file filled with 0xFF. Maybe it works.. Hi!

While waiting for the TRIM option, would it be of any use to fill the deleted sectors with 0xFF? Would the SSD consider it as erased or not?

Easy to try; when the disk is getting slower, just fill all free space with a file filled with 0xFF. Maybe it works..

]]> By: antiram http://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-for-ssds/comment-page-1/#comment-1976 antiram Thu, 12 Mar 2009 13:37:30 +0000 http://thunk.org/tytso/blog/?p=281#comment-1976 "On the other hand, if Intel releases ATA TRIM support next month, then it might not be worth my effort to add such a mount option to ext4." means this that TRIM is working NOW with ext4 or is a mount option required? SSDs with Indilinx Barefoot Controller (OCZ Vertex, Supertalent Ultradrive, both available) should have TRIM support. A OCZ moderator says that next firmware (next week or month) has TRIM support, but it is not working with linux. http://www.ocztechnologyforum.com/forum/showpost.php?p=351938&postcount=35 a german Supertalent distributor says that the Ultradrives with current firmware has TRIM support. Is there a easy way to check if TRIM is supported from the ssd (e.g. hdparm, dmesg) and if the kernel and filesystem is using it? “On the other hand, if Intel releases ATA TRIM support next month, then it might not be worth my effort to add such a mount option to ext4.”
means this that TRIM is working NOW with ext4 or is a mount option required?

SSDs with Indilinx Barefoot Controller (OCZ Vertex, Supertalent Ultradrive, both available) should have TRIM support.
A OCZ moderator says that next firmware (next week or month) has TRIM support, but it is not working with linux.
http://www.ocztechnologyforum.com/forum/showpost.php?p=351938&postcount=35
a german Supertalent distributor says that the Ultradrives with current firmware has TRIM support.

Is there a easy way to check if TRIM is supported from the ssd (e.g. hdparm, dmesg) and if the kernel and filesystem is using it?

]]> By: Ben Bucksch http://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-for-ssds/comment-page-1/#comment-1948 Ben Bucksch Thu, 05 Mar 2009 10:59:29 +0000 http://thunk.org/tytso/blog/?p=281#comment-1948 "Until ATA TRIM support becomes available, it will be advantageous to add support in ext4 for a block allocator option that aggressively reuses blocks above all else, and avoids using blocks that have never been allocated or used before" I think this will also help sparse files used as base for virtual disks for VMs. “Until ATA TRIM support becomes available, it will be advantageous to add support in ext4 for a block allocator option that aggressively reuses blocks above all else, and avoids using blocks that have never been allocated or used before”

I think this will also help sparse files used as base for virtual disks for VMs.

]]> By: Anon http://thunk.org/tytso/blog/2009/02/22/should-filesystems-be-optimized-for-ssds/comment-page-1/#comment-1893 Anon Thu, 26 Feb 2009 08:51:03 +0000 http://thunk.org/tytso/blog/?p=281#comment-1893 (Doh sent that message too soon) Some kernel devs are also predicting that the move to 4k sectors is going to be painful: http://lkml.org/lkml/2009/2/25/485 (but I see you've already seen that thread :) (Doh sent that message too soon)

Some kernel devs are also predicting that the move to 4k sectors is going to be painful: http://lkml.org/lkml/2009/2/25/485 (but I see you’ve already seen that thread :)

]]>