New answers tagged

1

If I understand you correctly, you want to use the free space on sdd2 for creating another Partition sdd3. To do that, you first need to resize the physical volume (if you haven't done that already) using pvresize. First have a look at how big your physical volume is using pvdisplay /dev/sdd2. If it already has the correct size, skip to the next step. ...


0

If the "partitions" are really managed within lvm, this is no problem. A single logical volume can span multiple physical volumes. However, you lose control over which disk gets which new chunk of data, so you might lose performance for new parts of files that are otherwise stored on SSD. I'm seconding Steweryn's dm-cache suggestion.


3

You could have a partition on two disks if you used Brtfs file system or LVM, but creating a partition on two disks will be similar in performance to moving /home to a spinning HDD. In your case you should probably take a look at dm-cache


0

The best way to recover in your situation is to detach the disk you have now attached to sda and attach this disk in question to sda, then boot from it. After you get to console, change all PV's UUIDs: pvchange -a -u change VG's UUID: vgchange -u VloGroupName and rename your volume group to a new name vgrename OldVolumeGroup{Path|Name|UUID} ...


2

You still need to resize the filesystem contained in the LV (assuming it's one of the ext filesystems): resize2fs /dev/mapper/vg_condor-lv_root If you want to resize a logical volume and its filesystem in a single operation, use fsadm: fsadm resize /dev/mapper/vg_condor-lv_root This supports the ext filesystems as well as ReiserFS and XFS.


0

I had this problem as well. In my case it was a combination of iscsi, multipath and lvm and the ordering of session creation etc. I solved the problem by adding a call to /sbin/vgchange -a y to /etc/rc.local.


1

I had the same issue. The debian maintainers added a patch to mdadm which causes the raid assembly to start before the devices are up. I have not yet completely found out why as it's supposed to fix broken RAIDs as root file system. But you can fix it for now by downgrading the mdadm package. Get the older version from here: ...


4

Presumably you already found this: http://serverfault.com/questions/528075/is-it-possible-to-on-line-shrink-a-ext4-volume-with-lvm so the short answer is "because the folks who wrote ext4 don't support this." The slightly longer answer is that it's hard, especially if maintaining any sort of backward compatibility with ext2. Finding all the bits and pieces ...


1

In this particular scenario, you have 3 primary and 1 extended partition. If you look at the output of fdisk -l and pay attention to /dev/sda2 End and /dev/sda3 Start, you have a bit of space there. My guess is that your only option is to move data from /dev/sda3 (/boot) partition over network or with some external media (USB etc), unmount /boot, delete ...


1

If you want to mirror the whole drive, the simplest method would be to turn it into a RAID-1 array. It's possible to turn an existing partition (or whole disk, or any volume type really) into an mdraid RAID-1 array, it just requires a bit of manual fiddling. The idea is to ensure that there's enough free space at the end of the volume (128kB) for the ...


1

You must have had a look at this page already, Online RAID1 Creation in Linux It will be really straight forward if you could get two brand new drives, put them in a newly created RAID1 mirror with mdadm and use dd to transfer data from /dev/sda. Or take a dd backup of your /dev/sda, use /dev/sdb to create a mirror and restore from backup. Or still use ...


0

Note: As a fair warning, you need to be careful when having logical volumes span across multiple disks. If one fails, you lose your entire volume group. I cannot stress this enough, there is a huge possibility of you losing your data if a drive fails or you delete a partition that's part of the volume group. You need to create a partition on both disks for ...


2

Your information is contradictory. /dev/md0 cannot simultaneously be a PV and have a partition table. file would recognize a PV. It seems that md0 is partitioned so that the LVM volume is rather /dev/md0p1 or /dev/md0p2. Maybe for some reason pvscan / vgscan ignore /dev/md0 / /dev/md0p1 (and thus LVM cannot find the UUID). You may run pvscan through strace ...


0

I've had the same issue, maybe little "deeper": up to the mount point level. In case anyone is interested, here are two functions I'm using, for querying both ways. ######## FIND THE LVPATH of an existing FS. Query the lvm using FS' mount point fileSystem_to_lvPath(){ FS_TO_QUERY=$1 #Call like this: $0 /tmp #Relevant commands for debug: blkid, ...


1

Do not forget to comment out or remove the line from /etc/fstab that refers to /home. If you leave this in then Linux gets confused shutting down and restarting.



Top 50 recent answers are included