LWN: Comments on "The second half of the 2.6.37 merge window"

'Support for the CAIF shared memory protocol has been added. '

jch — Thu, 11 Nov 2010 13:06:36 +0000

I was under the impression that CAIF is used internally by Android phones. It's for communication between the two CPUs in the phone, not for communicating with an external device.

--jch

The second half of the 2.6.37 merge window

slothrop — Sat, 06 Nov 2010 18:08:19 +0000

Good points,
I write ~30GB per week to my 30GB SSD (just one partition).
So I changed cron from running fstrim daily to twice a week.

The second half of the 2.6.37 merge window

Lope — Sat, 06 Nov 2010 04:27:11 +0000

If you do want to benchmark discard performance of you SSD you can use this tool :

http://sourceforge.net/projects/test-discard/

BUT, there are some very bad devices which might be corrupted by sending lots of small TRIM's so better be careful (Or blame your vendor for doing bad job!).

The second half of the 2.6.37 merge window

Lope — Sat, 06 Nov 2010 04:13:39 +0000

The question of how often do you want to run fstrim on the whole filesystem is a little tricky, because it depends on what type of workload you are running. If you are able to fill up you disk within one day you probably should reclaim the space (discard) at least one time a day, but on regular desktop I very much doubt that.

So, what you probably want to do (if you want to be exact) is to watch the amount of data written to the filesystem (you can do that through /sys/fs/ext4/<device>/lifetime_write_kbytes assuming that on <device> is ext4 fs) and when it is going to reach some threshold (like 80% of device size) you would need to start doing the discard (note that FITRIM on ext4 will return amount of reclaimed space). But all of this may be an awful overkill for simple desktop:). And aside of that there are some very bad devices out there which are showing significant performance regression even at 50% fs saturation. And of course if you have more partitions on the same device ... it gets even more complicated :)

All that said, if you are ok with doing it once a day (and you are not even noticing it) it is good thing to do. But if it disturbs you, you probably would not want to do it so often, or at least do it per partes (which you can do with a little scripting) through a longer period of time.

The second half of the 2.6.37 merge window

nix — Wed, 03 Nov 2010 16:49:38 +0000

You'd also need a holepunch operation in the overlying filesystem, to be able to insert holes in the middle of an existing file.

The second half of the 2.6.37 merge window

nye — Wed, 03 Nov 2010 16:45:02 +0000

Ah, that makes sense - thanks.

The second half of the 2.6.37 merge window

slothrop — Wed, 03 Nov 2010 15:31:02 +0000

I have performance problems with my first generation
Vertex SSD if I use the ext4 discard option. So in
this case it is better to run fstrim as a cron job every
night. But if you have a good SSD with a fast ATA trim
implementation, the discard mount option is just fine.

The second half of the 2.6.37 merge window

nye — Wed, 03 Nov 2010 15:18:48 +0000

>BTW a nice userspace program for the (ext4) FITRIM ioctl() command can be found here:

In what circumstances would you want to use this rather than just mounting with the 'discard' option?

I'm curious because I've just bought my first SSD and I'm wondering how best to maintain performance. At first I was thinking of reserving some unpartitioned space, but then it occurred to me that it would probably be better just to use an ext4 partition. That way I can use the space if I really need it at some point, but it can be 'reclaimed' by the SSD for its own purposes when there's nothing stored there. Is that not correct?

'Support for the CAIF shared memory protocol has been added. '

trancecode — Wed, 03 Nov 2010 11:48:18 +0000

Can anyone here point me to more info about the new CAIF protocol?

I read the docs and googled a bit but it is not clear to me how to use/test it.

Are there user space utilities available?
Is hardware essential? - I see a loopback implementation mentioned.
Do I need to buy a SonyEricsson Android phone for this to be useful?
(I might just do that if I can be sure to get one that will work)

The second half of the 2.6.37 merge window

butlerm — Tue, 02 Nov 2010 16:51:04 +0000

Nothing stops clients from trimming free 2MB blocks using 4K block trim operations...

The second half of the 2.6.37 merge window

tardyp — Tue, 02 Nov 2010 14:05:28 +0000

Seems one of the dev of vbox was answering on this topic a while ago.
http://forums.virtualbox.org/viewtopic.php?f=9&t=1822...
"""
VD images files are typically mapped onto physical rotating media. These have high burst bandwidth but poor seek times (compared to SSD). The VDI format uses 2Mb pages for performance reasons. Dropping this to 4K to align it to the SDD driver technology would have a disastrous impact on real I/O performance (up to a factor of 10 slowdown say). Sorry, but this is a dumb idea.
"""
This was not wrong 1 year ago.. now, I'm doing desktop virtualization on ssd laptop. I dont want my virtualdisk to grow undefinitively. I dont want spinning disk optimizations.

The second half of the 2.6.37 merge window

mokki — Tue, 02 Nov 2010 07:37:04 +0000

I think so. When the virtual block device run by virtualbox/kvm detects the trim command it could punch a hole to the disk image, freeing disk space.

The xfs has an ioctl for punching holes to files. unfortunately a fallocate flag for deallocating space from 2007 has not been included in mainline.

The second half of the 2.6.37 merge window

slothrop — Tue, 02 Nov 2010 07:24:46 +0000

That's an interesting idea, but it needs to be implemented
in virtualbox or qemu. Then you could issue the FITRIM
ioctl from the running guest and it would be intercepted
by these programs and acted upon accordingly.

The second half of the 2.6.37 merge window

bronson — Tue, 02 Nov 2010 06:39:49 +0000

Right. And if you tell virtualbox which blocks on the virtual disk are no longer used, the backing file can be made more sparse.

In theory, trim could be just as useful to loopback-mounted filesystems as it is to SSDs, no?

The second half of the 2.6.37 merge window

slothrop — Tue, 02 Nov 2010 04:51:40 +0000

No. This is not about reducing sizes, its about telling
your SSD which blocks are not used by the filesystem currently,
so that they could be added to the internal list of available
blocks. This hopefully makes the SSD snappier and faster.

The second half of the 2.6.37 merge window

BenHutchings — Tue, 02 Nov 2010 00:33:48 +0000

This is due to a botched disk upgrade; see mail on LKML.

The second half of the 2.6.37 merge window

corbet — Tue, 02 Nov 2010 00:11:43 +0000

Linus forgot to push out the last stuff he committed, but it's there now.

The second half of the 2.6.37 merge window

nteon — Tue, 02 Nov 2010 00:06:01 +0000

is there a reason linus's tree at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-... doesn't have anything after 2.6.36-rc6? Did it move, or get rolled back for some reason?

The second half of the 2.6.37 merge window

tardyp — Mon, 01 Nov 2010 23:16:04 +0000

Do you think this could be used to reduce the size of virtualbox'es variable size virtual disks?

The second half of the 2.6.37 merge window

slothrop — Mon, 01 Nov 2010 21:31:00 +0000

It now can also be found on sourceforge:
http://sourceforge.net/projects/fstrim/

The second half of the 2.6.37 merge window

slothrop — Mon, 01 Nov 2010 21:22:32 +0000

BTW a nice userspace program for the (ext4) FITRIM ioctl() command
can be found here:
http://www.spinics.net/lists/xfs/msg01837.html
It's called fstrim and works nicely on my Vertex SSD.
Compile and run as root (e.g.): fstrim -v /
(There is no visible feedback, you have to wait a few minutes
(depending on the size and state of the SSD) before it finishes.)