Tag Info

New answers tagged

0

I tried to do it using pvmove and it didn't work. There is a reference on Google to a fix to the source code that would enable the pvmove command to allow for this but on my CentOS 7 machine it complained about my thin pool so I don't know what version, if any, this fix is included in. Nor do I know if it works. That said, moving an LVM from one pool to the ...


2

It depends on hybrid drive type: new Seagate SSHD drives manufactured since late 2013 have far better caching than earlier models. What is also important, bcache caching strategy is totally different than Seagate Adaptive Memory strategy, and while bcache is very fast in benchmarks, AM learns data topology and can outperform bcache in real situations, eg.: ...


2

If you format a piece of the SSD drive to be used as a bcache cache, then it will not be available anymore to store any other filesystem, obviously. But nothing prevents you from using the remaining part of the SSD drive as you see fit. This applies to for instance WD Black2 There are also other SSHD disks, like Seagete Momentus XT, where the cache is ...


1

You are using the Linux Logical volume manager (LVM). This is a layer between your physical disks and your filesystems that introduces the concepts of 'physical volumes' (PV), 'volume groups' (VG), and 'logical volumes' (LV). In your setup, /dev/sdb1 and /dev/sda2, the partitions of type "Linux LVM" are both physical volumes. On top of these PV you will ...


0

i use this method , not sure if it's the best but works for me use it with caution and not SysAdmin calculate the difference that cause the problem 324%4 = 0 no problem but 324%32 = 10.125 that's the problem so it doesn't fit i think it's called "get real number" lvmdiskscan to list involved partitions then pvresize /dev/*** ...


1

To play with DRBD, you'd be better off adding a new virtual disk to your VM and using that (alongside your existing disk) rather than trying to carve up the virtual disk you already have. As to your questions regarding LVM, the free space you're seeing displayed by the various tools is measured with different frames of reference. PVs are physical devices ...


2

On arch linux, there is an AUR package dropbear_initrd_encrypt that does what you want out of the box. Works pretty well for wired interfaces. I had to hack it up slightly for wireless.


0

The luks encryption header does not depend on or record the size of the underlying device. If you simply dd an encrypted partition into a larger encrypted partition, then when you open the new larger partition with cryptsetup luksOpen, its underlying size will be larger, too. If you are using that to store an LVM physical volume, then just run pvresize ...


2

Assuming your volume group is already full, and you cannot extend it further, you will need to: Shrink the filesystem in lv_home using the specific tools for your filesystem, e.g. resize2fs if you use ext3/4. Resize lv_home accordingly with lvreduce. Increase lv_root with lvresize. Increase the filesystem in lv_root so that it uses all the additional ...


2

First off, you want to unmount the partitions in question. Boot an usb stick or similar. Backing up important data is always recommended before fiddling with filesystems. Reduce the filesystem first in /dev/mapper/vg_dckapstaging-lv_home. Otherwise, resizing the lv will drop the data. The way to do it depends naturally from filesystem. resize2fs works for ...


1

This is a risky operation you should try to clean / (have a look at /var/log /var/spool and delete old and big file) theorical way to proceed include fsck -F /dev/mapper/vg_dckapstaging-lv_home lvresize --size -15G /dev/mapper/vg_dckapstaging-lv_home resize2fs /home lvresize --size +15G /dev/mapper/vg_dckapstaging-lv_root resize2fs / Disclaimer 3.1. be ...


1

You should have --private option for vzctl create: vzctl create CTID --private /vz/primary vzctl create CTID --private /vz/secondary If each container has a dedicated partition, also consider specifying --layout simfs. ploop might be unneeded overhead.


1

I fixed it! Here are the commands I used this time: # parted /dev/sda (parted) mklabel msdos (parted) mkpart primary ext2 2MiB 2GiB (parted) mkpart primary ext4 2GiB 100% (parted) set 1 boot on (parted) q # mkfs.ext2 /dev/sda1 # cryptsetup --key-size 512 --hash sha512 --iter-time 5000 --use-random luksFormat /dev/sda2 # cryptsetup open --type luks ...


0

In general, you should try to have as few VGs as possible (VGs can be spanned across multiple PVs with vgextend). It makes things easier to manage when a single VG spans all PVs and you can just use pvmove to migrate LVs to a different physical device. What I've found over the years with Software RAID, as you get into the larger disk sizes, is that ...


6

Most init systems probably won't expect this situation so they won't be prepared to first assemble LVM, then MD, then LVM again. If you put LVM below MD you have to be very careful. MD is supposed to be used with physical disks, but with LVs as RAID members you could easily end up with two members sharing the same disks. That is if using MD as a standalone ...


2

Don't install a new system unless you want to redo your system configuration from scratch. Note that you may want to do that — copy your home directory over, and progressively restore the system configuration, taking care to 1. install etckeeper as soon as you've rebooted after the system installer and 2. not make changes outside of /etc and your home ...



Top 50 recent answers are included