Hello,
I have a thought for a new feature / application for unionfs and would
like to get some feedback from people who know the code well enough to
determine its feasability.
I work for Coraid, Inc. As a storage vendor, we routinely meet people
who want scalable ways to expand their storage, incrementally. We've
authored articles in Linux Journal and Linux Magazine on how to
achieve this with LVM, an option many users have taken. This approach
has an unfortunate downside that unless micromanaged, a physical
volume (pv) can be allocated to more than one logical volume (lv).
When that pv goes down it takes down all the logical volumes it's a
part of. There's no mounting a filesystem that has random portions of
its block storage missing. For many of our users, managing pv
allocation is very challenging.
We started looking at unionfs as a way to allow users to accomplish
the same goal with a different approach. Namely, if you want to grow
an existing disk+fs store, just add another disk+fs and union them
together. Then if one disk goes away, at least you still have *some*
files while you work on figuring out what went wrong. It's a more
natural way to think about what they really want to achieve.
Not surprisingly, the current implementation of unionfs does not
achieve this well. That is not a critique, it just wasn't designed
for it. To illustrate, we have two options:
1. Make a union with the old fs ro and the new one rw.
This approach is that by design every modified file gets copied to the
new store resulting in a large reduction of total store in the event
the larger files on your old store were frequently modified. In the
event this store backs user directories, a simple "find ~ --exec touch
{} ';'" will cause a users entire home directory tree to be copied.
Additionally, unless the old fs is full, you've wasted whatever store
you had left.
2. Make a union with both fs rw.
This approach leaves the new fs unused except when creating new
directory trees and the old fs can still eventually fill up.
It seems like the current feature set is already very close to
supporting this, needing only a minor modification to be useful. All
that is really needed is a copyup followed by a subsequent unlink.
Pseudocodically:
writefile(f) {
if (fs(f).bind == ro) {
copyup(f);
} else if (migrate && fs(f).isfull) {
copyup(f);
unlink(f); // from old location
} else
write(f);
}
That's fast and loose, but hopefully you get the point. The "full"
indication could be a percentage of filesystem usage or whatever knob
seems more natural.
Further features might include copydown if the old fs ends up less
full than the newer one(s) and migrating trees between binds through
unionfs.
Anyway, thoughts? We're currently on the cusp of writing an article
on using unionfs for scalable storage. We can find a use case using
largely static content where the current functionality will suffice,
but this seemingly minor change could really open up the article to
more general applications.
Cheers,
Sam
_______________________________________________
unionfs mailing list
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
