Mike Snitzer wrote:
On Wed, Oct 21 2009 at 11:05pm -0400,
Douglas McClendon <dmc.fedora@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Has anyone looked into the idea of dm-snapshots responding
appropriately to trims from filesystems?
I.e. the efficiency problem of a dm-snapshotted ext filesystem
having files created and then deleted? I.e. in such a scenario,
resources in the cow device end up taken that could be freed if the
dm layer could efficiently respond to trim notifications by
discarding any useless exceptions?
I've been poking around pondering whether an offline quick hack
might be possible with libext2fs and enough knowledge of the on-disk
persistent snapshot format. I.e. just walk the exception chunks in
the cow device, use libext2fs (sufficient? easiest way?) to
determine whether all the fsblocks/sectors the chunk contains are
all currently unneeded, and if so reclaiming that space (possibly by
relocating the last exception. I'm still a distance from truly
grokking the on-disk format along with the rest of the dm-snapshot
and exception-store code).
Does any of this make sense? Been looked at? Seem like a
reasonable avenue to pursue?
The snapshot must faithfully maintain a copy of the origin's data
relative to a particular point in time. You can't use changes to the
origin (trim or any other change) to delete the exceptions that a
snapshot is already maintaining. That would invalidate the whole intent
of the snapshot.
I wasn't asking about trimmable dm-snapshot-origin devices, only
trimmable[1] dm-snapshot devices.
Thinking about snapshot-origin devices, what you say is a valid reason
why such optimization is not remotely easy (or feasible at all).
But for snapshot devices, I think the optimization should be as simple
and effective as I described it. (until I discover some other aspect of
dm that changes my understanding of things).
[1] http://lwn.net/Articles/293658/
-dmc
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
