On Sun, Feb 08, 2009 at 11:47:25AM -0500, Ric Wheeler wrote: > Matthew Wilcox wrote: > >I thought we had agreed on a plan which satisfied the SSD and insane > >array vendors. That is that we would do no tracking of allocation units > >in the filesystem, but instead extend each trim out to cover the maximum > >possible size. I've confirmed with Intel's SSD people that this would > >cause them no harm at all (trimming already trimmed sectors won't even > >cause a slowdown). Whether the filesystem people have taken note of > >this, I have no idea. > > That should be helpful for the array people, but for some of them with > really large delete chuck sizes, they will still miss a lot since their > size is larger than the average file size :-) I guess that we could do > something to resync - Ted mentioned some ideas for ext4. I'm not sure I communicated the plan effectively. Let's consider deleting a 4k file. The DISCARD that the filesystem sends down does not just cover the 4k of data. It covers all adjacent free space to that 4k of data, so it might end up sending a DISCARD of several megabytes or even gigabytes, assuming there's that much contiguous free space. Now, filesystems which fragment their free space will not do well on thin provisioned devices, but then they won't do well on any devices -- keeping your free space compacted is an essential part of any filesystem's job, even on SSDs. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
