On Thu, Jan 06, 2011 at 09:10:29AM +0100, 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.
Sure, but the way xfs_fsr skips it is by physically checking the
inode on the next filesystem pass. It does that efficiently because
the necessary information is cheap to read (via bulkstat), not
because we track what needs defrag in the filesystem on every
> 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.
Sure, but the block device should, and therefore a TRIM to an area
with nothing to trim should be fast. The current generation drives
still have problems with this, but once device implementations are
better optimised there should be little penalty for trying to trim a
region that currently holds no data on the device.
basically we need to design for the future, not for the limitations
the current generation of devices have....
> > 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.
A filesystem does not necessarily reuse the same blocks for
temporary data. That "5%" of data that is written and erase all the
time could end up spanning 50% of the filesystem free space over the
period of a week....
> 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.
So, lets keep a "used free space" tree in the filesystem for this
purpose. I'll spell out what it means in terms of runtime overhead
Firstly, every extent that is freed now needs to be inserted into
the new used free space tree. That means transactions reservations
all increase in size by 30%, log traffic increases by 30%, cpu
overhead increases by ~30%, buffer cache footprint increases by 30%
and we've got 30% more metadata to write to disk. (30% because there
are already 2 free space btrees that are updated on every extent
Secondly, when we allocate an extent, we now have to check whether the
extent is in the used free space btree and remove it from there if
it is. That adds another btree lookup and modification to the
allocation code, which adds roughly 30% overhead there as well.
That's a lot of additional runtime overhead.
And then we have to consider the userspace utilities - we need to
add code to mkfs, xfs_repair, xfs_db, etc to enable checking and
repairing of the new btree, cross checking that every extent in used
free space tree is in the free space tree, etc. That's a lot of work
on top of just the kernel allocation code changes to keep the new
tree up to date.
IMO, tracking used free space to optimise background trim is
premature optimisation - it might be needed for a year or two, but
it will take at least that long to get such an optimisation stable
enough to consider for enterprise distros. And at which point, it
probably isn't going to be needed anymore. Realistically, we have
to design for how we expect devices to behave in 2-3 years time, not
waste time trying to optimise for fundamentally broken devices that
nobody will be using in 2-3 years time...