Gus Wirth wrote: > SJS wrote: >.. >> With LVM, is it even simpler? > > Yes. But you have to have empty space beforehand to allocate. Or you > have to do some gyrations to shrink a filesystem that has excess space > in order to reallocate it to the filesystem that needs it. Answers at > <http://www.tldp.org/HOWTO/LVM-HOWTO/index.html> > >> Where are my bits, exactly? > > That is a much better question. They answer is, no one knows, exactly. > Well, at some level the operating system figures it out, but the answer > is convoluted involving potentially many redirects.
So what is the future of this convoluted mess? I'm thinking that LVM, per se, is mostly a control-interface (manager, I guess) to device-mapper -- would that be a reasonable way to put it? Whether that's right or not, it's still convenient to call the resulting capabilities LVM. Now, it strikes me that the unique contribution by LVM is snapshot and data migration (pvmove). That is, could not the re-allocation stuff be done outside of LVM? Though I suppose, perhaps not as dynamically, eh? Or, perhaps another question might be: could LVM conceivably me merged into the block device (or could lvm subsume the block device?) What I'm getting at is, can a layer of indirection be removed? Assume that I'm thinking of a device as a single physical drive or portions thereof. [We'll talk about md, another day -- or is it important here?] Maybe that extra level is unavoidable for certain conditions (namely snapshot and pmove, I might guess) -- might it be possible to dynamically patch the indirection in and out (or is that some kind of code-modification heresy?) so that the inefficiency and complication exists as a temporary state. 'Course calling it temporary, may be wishful thinking, but at least it would be optional, and no worse than now. Am I talking any sense, here? Is removing indirection/complication worth the pain? Regards, ..jim -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
