Tag Info

Hot answers tagged

51

LVM is designed in a way that keeps it from really getting in the way very much. From the userspace point of view, it looks like another layer of "virtual stuff" on top of the disk, and it seems natural to imagine that all of the I/O has to now pass through this before it gets to or from the real hardware. But it's not like that. The kernel already needs to ...


11

I think you are looking for lvconvert --merge. From the man page: --merge Merges a snapshot into its origin volume. To check if your kernel supports this feature, look for snapshot-merge in the output of dmsetup targets. If both the origin and snapshot volume are not open the merge will start immediately. Otherwise, the merge ...


10

A guide to do such a setup with BusyBox and Dropbear is shown in this blog post. early-ssh didn't work for me and is apparently not needed anymore. I have summarized what you need to do in the following. For more details, have a look at the post above: Install BusyBox and Dropbear on your server sudo apt-get install dropbear busybox Update your ...


10

I think early-ssh provides what you're searching for: Early-ssh is a simple initramfs hook, which installs Dropbear SSH server into your initramfs, and starts it at boottime, so you will be able to do a lot of things remotely over SSH, before your root partition gets mounted, for example: * unlocking LUKS encrypted crypto devices - even your root ...


10

Yes. You can create a VMDK (not a VDI — you have to use the VMware disk image format) that accesses a raw disk. You can easily use a logical volume as if it were a whole disk, but just like most virtual disks, you probably won't be able to make the host kernel interpret its partition table and mount it. Once you create your volume, just run VBoxManage ...


10

You can use pvmove to move those extents to the beginning of the device or another device: sudo pvmove --alloc anywhere /dev/device:60000-76182 Then pvmove chooses where to move the extents to, or you can specify where to move them. See pvs -v --segments /dev/device to see what extents are currently allocated.


9

LVM, like everything else, is a mixed blessing. With respect to performance, LVM will hinder you a little bit because it is another layer of abstraction that has to be worked out before bits hit (or can be read from) the disk. In most situations, this performance hit will be practically unmeasurable. The advantages of LVM include the fact that you can add ...


9

I just had a similar problem to what you describe, though for me it happened when I was attempting to install the new Ubuntu 11.10 Oneiric Ozelot to an LVM volume. I had done the following to set lvm up on a live boot system (the logical volumes I needed were already present): apt-get install lvm2 vgscan --mknodes -v Now lvscan -v showed my volumes but ...


9

Pro: you don't waste one disk sector on a partition table. (Yay.) Pro: the disk can be used in an operating system that doesn't support PC-style partitions. (Like you're going to use one.) Con: this is unusual and may confuse co-sysadmins. (See?) Irrelevant: extending the filesystem is not easier if it's directly on the disk than if it's in a partition, ...


9

The two main ingredients are hdparm --fibmap file, which tells you where the file is physically located within the LV, and lvs -o +seg_pe_ranges,vg_extent_size which tells you where the LV is physically located on your device(s). The rest is math. So, for example: # hdparm --fibmap linux-3.8.tar.bz2 linux-3.8.tar.bz2: filesystem blocksize 4096, begins ...


8

First of all the hassle with encrypted root and early userspace is typically already handled by your distribution (as far as i know Fedora, Debian, Ubuntu and OpenSUSE support encrypted root out of the box). That means you don't have to care for the setup itself. One reason for encrypting / is just to be sure you don't leak any information at all. Think ...


7

I found the LVM HOW-TO to be very clear. It has probably more info than you want from a first-time tutorial, but reading sections 1. to 3. and 11. to 13. should give you a comprehensive introduction to LVM concepts and its usage in live systems; these days, most Linux distribution have good LVM support out-of-the-box, so you can safely skip the ...


7

On Debian (and hopefully your distro as well) all the LVM metadata is already loaded into udev (by some of the rules in /lib/udev/rules.d). So you can use a rules file like this: $ cat /etc/udev/rules.d/92-local-oracle-permissions.rules ENV{DM_VG_NAME}=="vgRandom" ENV{DM_LV_NAME}=="ora_users_*" OWNER="oracle" ENV{DM_VG_NAME}=="vgRandom" ...


7

Warning, wall of text incoming. It's as well formatted as I could make it. If we're going to answer this, we're going to answer the whole thing. I'm not doing another answer on this, so here goes: Let's pretend you know absolutely nothing, and I'm feeding you keystrokes. This tells you everything you need to know to do this WHOLE thing, with a little ...


7

/etc, /var, and /tmp come to mind. All can potentially have sensitive contents. All can be given separate volumes, but it's common for each of these to be on the same filesystem as the root directory. Maybe you've moved one or more off into their own volumes, but have you moved them all? /etc contains: hashed passwords; possibly multiple sorts, such as ...


7

There're handy dmsetup ls --tree and lsblk utils.


7

-l 100%VG will try to extend the logical volume so that its total size is equal to the volume group's total size. This is not what you want - you already have another logical volume in that VG, which is taking space. If you want the logical volume to use all the available free space in the volume group, the switch should be -l +100%FREE (i.e. make the new ...


7

It's preferable to have some commonly recognized descriptors (meta-data) and MBR does quite stand as such a descriptor. Even GPT uses old MBR-based partition table to indicate its presence. Indeed you lose some diskspace but it's rather negligible meanwhile advantage of understanding what's on the disk (and where) is self-evident.


6

LVM on top of anything is probably a good idea because it gives you quite a bit of flexibility at pretty marginal cost (the extra abstraction layer is really cheap compared to disk I/O). That said, I'd use RAID6, as RAID5 leaves you with no redundancy during a rebuild, which is precisely the time of high stress where drives are most likely to fail.


6

It would be a good idea to use LVM on top of RAID. Then you can grow the RAID array and also grow the LV.


6

If this is an ext3 filesystem, you can extend it to the LV size by running: resize2fs /dev/system/var If this anything else than ext3, use the appropriate tool, e.g. xfs_growfs /var if it's XFS. This is absolutely nothing to be afraid of. I have extended hundreds of filesystems in more than 10 years on several operating systems and I have never seen ...


6

Simple answer: No. If you want LVM you need an initrd. But as others have said before: LVMs don't slow your system down or do anything bad in another way, they just allow you to create an environment that allows your kernel to load and do its job. The initrd allows your kernel to be loaded: If your kernel is on an LVM drive the whole LVM environment has to ...


6

With lvm on top of a raid device you are flexible to create multiple virtual devices (and filesystems) on it. And you are flexible to change the size of those devices. If you are 100% sure that you don't need that and you only need one big filesystem, then you can directly create the filesystem on your raid device. One layer of indirection and complexity is ...


6

I suggest using a different testing method. hdparm is a bit weird as it gives device addresses rather than filesystem addresses, and it doesn't say which device those addresses relate to (e.g. it resolves partitions, but not devicemapper targets, etc.). Much easier to use something that sticks with filesystem addresses, that way it's consistent (maybe except ...


6

When you're using ext4, you can check for badblocks with the command e2fsck -c /dev/sda1 or whatever. This will "blacklist" the blocks by adding them to the bad block inode. e2fsck -c runs badblocks on the underlying hard disk. You can use the badblocks command directly on a LVM physical volume (assuming that the PV is in fact a hard disk, and not some ...


5

In my opinion one of the best resources for LVM was Red Hats LVM Administrators Guide, check it out.


5

Those are file descriptors left open on the device (which you were resizing). lvm(8) says: On invocation, lvm requires that only the standard file descriptors stdin, stdout and stderr are available. If others are found, they get closed and messages are issued warning about the leak.


5

Not sure about how this would apply to Linux but with native ZFS, one reason it is recommended to create pools on whole disks and not partitions is in the former case the disk write cache can be enabled. Several other reasons also mentioned here: http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#Storage_Pools Conclusion: it works, ...


5

LVM does support read-write snapshots in fact that's the default. Merging a modified snapshot will delete the data on the snapshot origin volume the same way merging an unmodified snapshot would. If you expect to discard modifications then I recommend RW snapshots and merge if you want to keep them. If you expect to keep the modifications then you should ...


5

I've implemented support for storing your LUKS key in TPM NVRAM, and RHEL6 happens to be the one platform where all features are fully tested, see this post: [1] http://security.stackexchange.com/a/24660/16522



Only top voted, non community-wiki answers of a minimum length are eligible