On Mon, 15 Jul 2013, Craig Sanders wrote:
On Sun, Jul 14, 2013 at 05:25:29PM +1000, Brett Pemberton wrote:
to extend or resize the volume, you've got to tell it which disk(s) to allocate the free space from.
Nope. You can, but you don't have to.
oh well, consider that an example of lvm's difficulty to learn and remember. I've been using LVM for a lot longer than ZFS but I still find it difficult and complicated to work with, and the tools are clumsy and awkward.
Really? You haven't come across HP-UX's LVM or veritas cluster storage's lvm then :) I find zfs obtuse, awkward, inflexible, prone to failure and unreliable. One day when I got sick of the linux kernel's braindead virtual memory management, I tried to install debian kfreebsd, but gave up before I finished installation because not having lvm seemed so primitive. I was probably just trying to use the wrong tool for the job.
nowadays, i see them as first generation pool & volume management tools, functional but inelegant. later generation tools like btrfs and ZFS not only add more features (like compression, de-duping, etc etc) by blurring the boundaries between block devices and file systems but more importantly they add simplicity and elegance that is missing from the first generation.
Does anyone use zfs's dedup in practice? Completely useless. Disk is a heck of a lot cheaper than RAM. Easier to add more disk too compared to maxing out a server and having to replace *everything* to add more RAM (dissapointingly, I didn't pay $250 to put 32GB in my new laptop. I hoped to replace the 16GB with 32GB when it becomes more economical, but when I opened it up, I found there were only 2 sockets. According to the manual that wasn't supplied with the laptop, the other two sockets are under the heatsink wedged underneath the keyboard, and not user-replacable. According to ebay, within the past couple of weeks, they did start selling 16GB sodimms, but no idea whether my haswell motherboard will be able to take them when it comes time to upgrade (which is probably very soon, judging by how iceape's memory usage just bloated even futher beyond reasonableness)).
and as for lvextend, lvreduce, and lvresize - it's completely insane for there to be three tools that do basically the same job. sure, i get that there are historical and compatibility reasons to keep lvextend and lvreduce around, but they should clearly be marked in the man page as "deprecated, use lvresize instead" (or even just "same as lvresize")
Au contraire. If you use lvresize habitually, one day you're going to accidentally shrink your LV instead of expand it, and the filesystem below it will then start accessing beyond end of device, with predictably catastrophic results. Use lvextend prior to resize2fs, and resize2fs shrink prior to lvreduce, and you'll be right. -- Tim Connors