xfs: add FITRIM support

[Lukas Czerner]

On Thu, 6 Jan 2011, Lukas Czerner wrote:

> On Thu, 6 Jan 2011, Michael Monnerie wrote:
> 
> > On Mittwoch, 5. Januar 2011 Dave Chinner wrote:
> > > No state or additional on-disk
> > > structures are needed for xfs_fsr to do it's work....
> > 
> > That's not exactly the same - once you defraged a file, you know it's 
> > done, and can skip it next time. But you dont know if the (free) space 
> > between block 0 and 20 on disk has been rewritten since the last trim 
> > run or not used at all, so you'd have to do it all again.
> >  
> > > The background trim is intended to enable even the slowest of
> > > devices to be trimmed over time, while introducing as little runtime
> > > overhead and complexity as possible. Hence adding complexity and
> > > runtime overhead to optimise background trimming tends to defeat the
> > > primary design goal....
> > 
> > It would be interesting to have real world numbers to see what's "best". 
> > I'd imagine a normal file or web server to store tons of files that are 
> > mostly read-only, while 5% of it a used a lot, as well as lots of temp 
> > files. For this, knowing what's been used would be great.
> > 
> > Also, I'm thinking of a NetApp storage, that has been setup to run 
> > deduplication on Sunday. It's best to run trim on Saturday and it should 
> > be finished before Sunday. For big storages that might be not easy to 
> > finish, if all disk space has to be freed explicitly.
> > 
> > And wouldn't it still be cheaper to keep a "written bmap" than to run 
> > over the full space of a (big) disk? I'd say depends on the workload.
> > 
> 
> I have already investigated approach with storing the information about
> blocks freed since last trim. However I found it not that useful for
> several reasons.
> 
> 1. Bitmaps are big, especially on huge filesystems you are talking about
> it will significantly increase the memory utilization.
> 
> 2. Rbtree might be better, however there is some threshold we need to
> watch, because when it gets really fragmented it can be bigger than
> bitmap. Moreover it adds significant complexity and of course CPU
> utilization.

Not talking about the fact that neither bitmaps not rbtrees can survive
umount.

> 
> 3. As I said several times, we do not need to trim when there was not
> enough writes from the last trim, because when we have enough space for
> example for wear leveling in SSD, we do not need to reclaim more, OR we
> can do is really slowly as a precaution measure.
> 
> All that said, we have much more flexibility in user space and we can
> think of a lots of different heuristic to determine whether or not to do
> the trim and how.
> 
> Thanks!
> -Lukas
>