-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/30/2016 04:15 AM, Zdenek Kabelac wrote:
> Hi
>
> Please provide full 'vgchage -ay -' trace of such activation
> command.
>
> Also specify which version of lvm2 is in use by your distro.
2.02.133-1ubuntu10. I ended up fixing it by doing
I seem to remember ( and found some references on the web ) that there
used to be a way to change the allocation policy when creating a mirror
from the default of strict ( must use different pvs ), but I can't find
a mention of strict in the man pages these days. I did see the option
for --alloc
Alasdair G Kergon writes:
> On Tue, Jan 05, 2021 at 02:31:00PM -0500, Phillip Susi wrote:
>> How can I forge it to make the mirror on a single pv?
>
> If --alloc anywhere isn't doing the trick, you'll need to dig into
> the - output to try to understand why. There m
Alasdair G Kergon writes:
> So despite that, it's not letting you have the 'anywhere' for the log
> part of the allocation.
Based on the number of extents it said it was looking for, I didn't
think it was the log that it couldn't place.
> However, for what you are doing, maybe you don't need
Tomas Dalebjörk writes:
> hi
>
> I think I didn’t explain this clear enough
> Allthe lvm data is present in the snapshot that I provision from our backup
> system
> I can guarantee that!
>
> If I just mount that snapshot from our backup system, it works perfectly well
>
> so we don’t need
I'm confused. What exactly are you trying to do here? I can't think of
any reason why you would want to copy a snapshot lv to a file then try
to loop mount it.
Tomas Dalebjörk writes:
> Hi,
>
> I am trying to understand how to convert a disk containing snapshot data.
> This is how I tested
Stuart D Gathman writes:
> 1. Unnecessary copying. 2. You lose your free backup of the system on
> the old drive,
>which should be carefully labeled and kept handy for a year.
>(After that, SSDs start to run the risk of data retention issues.)
You also have unnecessary copying with
"Brian J. Murrell" writes:
> Because I need to add another member to the array that is just slightly
> smaller than the existing array. It's the same sized disk as what's in
> the array currently but is itself an MD array with luks, which is
> reserving it's own metadata region from the total
"Brian J. Murrell" writes:
> I can shrink this array down to 3,906,886,464 without impacting the PV
> (and it's contents) correct?
Looks that way. That would be how much space is left in the array that
is not quite enough for another 4 MiB PE.
> From my calculations there is 4,022,272 bytes
"Brian J. Murrell" writes:
> Just to take advantage of MD's online/background sync to get the data
> from md0 array to the md1 array.
If you weren't using LVM, then that would be a good idea, but LVM can do
that too.
___
linux-lvm mailing list
"Brian J. Murrell" writes:
> So just to confirm, given:
>
> sdc 8:32 0 3.7T 0 disk
> └─md0 9:00 3.7T 0 raid1
> ├─backups-backups 253:13 0 2.5T 0 lvm
>
"Brian J. Murrell" writes:
> But I did just think of the other benefit of using MD to sync the new
> device and that's having a recovery path.
>
> That is, if I add luks-backup to /dev/md0 and then wait for it to
> finish syncing, I can then shut down the machine, remove /dev/sdc from
> the
Stuart D Gathman writes:
> Use dd to copy the partition table (this also often contains boot code)
> to the new disk on USB.
> Then use dd to copy the smaller partitions (efi,boot). Now use cfdisk
> to delete the 3rd partition. Expand the boot partition to 1G (you'll
> thank me later).
>
graeme vetterlein writes:
> I was able to "replace" 1 broken 2TB 1 working 2TB drive with a new
> 4TB drive
> without any filesystem creation, copying etc, just using LVM commands:
> umount /dev/mapper/SAMSUNG_2TB-data
> umount /dev/mapper/SAMSUNG_2TB-vimage
> lvchange -an
graeme vetterlein writes:
> I have a desktop Linux box (Debian Sid) with a clutch of disks in it
> (4 or 5) and have mostly defined each disk as a volume group.
Why? The prupose of a VG is to hold multiple PVs.
> Now a key point is *some of the disks are NAS grade disks.* This means
> they
15 matches
Mail list logo
