Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #229864 > unrolled thread

adding a disk to a Volume group

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  adding a disk to a Volume group mick crane <mick.crane@gmail.com> - 2020-12-20 20:10 +0100
    Re: adding a disk to a Volume group deloptes <deloptes@gmail.com> - 2020-12-20 21:10 +0100
    Re: adding a disk to a Volume group Charles Curley <charlescurley@charlescurley.com> - 2020-12-20 21:40 +0100
      Re: adding a disk to a Volume group Michael Stone <mstone@debian.org> - 2020-12-21 16:20 +0100
      Re: adding a disk to a Volume group elvis <elvis@dogonfire.com> - 2020-12-22 13:30 +0100
        Re: adding a disk to a Volume group Michael <ml@hemathor.de> - 2020-12-22 22:20 +0100
          Re: adding a disk to a Volume group Michael <ml@hemathor.de> - 2020-12-22 23:30 +0100
            Re: adding a disk to a Volume group Andy Smith <andy@strugglers.net> - 2020-12-23 04:40 +0100
              Re: adding a disk to a Volume group <tomas@tuxteam.de> - 2020-12-23 12:00 +0100
          Re: adding a disk to a Volume group elvis <elvis@dogonfire.com> - 2020-12-22 23:30 +0100

#229864 — adding a disk to a Volume group

hello,
It's a more or less new bullseye installation.
The installer kindly set up a Volume Group and added Logical Volumes of 
a couple of the partitions on the disk with the OS on it.
I want to add another disk to use for data.
Not had anything to do with LVM.
I'll want to make an extended partition of the whole disk first with 
fdisk.
but not sure the order I need to do things in after that.
Can see what VG is called with "vgdisplay"
will "vgextend my_VG /dev/sdx1"
sort out making the Physical Volume and the Logical Volume ?
I don't want to end up making 2 Volume Groups or something daft.
Is there any difference making the ext4 filesystem on the /dev/VG/LV or 
/dev/sdx1 ?

mick

-- 
Key ID    4BFEBB31

[toc] | [next] | [standalone]

#229866

mick crane wrote:

> I'll want to make an extended partition of the whole disk first with
> fdisk.
> but not sure the order I need to do things in after that.
> Can see what VG is called with "vgdisplay"
> will "vgextend my_VG /dev/sdx1"
> sort out making the Physical Volume and the Logical Volume ?
> I don't want to end up making 2 Volume Groups or something daft.
> Is there any difference making the ext4 filesystem on the /dev/VG/LV or
> /dev/sdx1 ?

you create first physical -> group -> logical volume and format.

you can also extend a logical group

https://wiki.debian.org/LVM

[toc] | [prev] | [next] | [standalone]

#229867

On Sun, 20 Dec 2020 19:05:45 +0000
mick crane <mick.crane@gmail.com> wrote:

> It's a more or less new bullseye installation.
> The installer kindly set up a Volume Group and added Logical Volumes
> of a couple of the partitions on the disk with the OS on it.
> I want to add another disk to use for data.

A couple of thoughts here.

* Are you adding the new disk permanently or as removable media?

  If the latter, put a separate VG on it. Or don't bother. The reason I
  suggest this is if the new disk is removable, having the same VG span
  both disks may make the permanent disk unusable if the removable one
  is gone.

  If it is permanent, consider redoing both of them as a RAID level
  1, with encryption and LVM on top of that. Be sure to leave a boot
  partition on at least one of them.

* You said nothing about encryption. That may impact the order in which
  you do things.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#229892

On Sun, Dec 20, 2020 at 01:38:16PM -0700, Charles Curley wrote:
>* Are you adding the new disk permanently or as removable media?
>
>  If the latter, put a separate VG on it. Or don't bother. The reason I
>  suggest this is if the new disk is removable, having the same VG span
>  both disks may make the permanent disk unusable if the removable one
>  is gone.

any LVs that have extents on the missing disk will be unavailable, but 
LVs entirely on the available disks should be fine. 

[toc] | [prev] | [next] | [standalone]

#229911

On 21/12/20 4:27 pm, mick crane wrote:
> On 2020-12-20 20:38, Charles Curley wrote:
>> On Sun, 20 Dec 2020 19:05:45 +0000
>> mick crane <mick.crane@gmail.com> wrote:
>>
>>> It's a more or less new bullseye installation.
>>> The installer kindly set up a Volume Group and added Logical Volumes
>>> of a couple of the partitions on the disk with the OS on it.
>>> I want to add another disk to use for data.
>>
>> A couple of thoughts here.
>>
>> * Are you adding the new disk permanently or as removable media?
>>
>>   If the latter, put a separate VG on it. Or don't bother. The reason I
>>   suggest this is if the new disk is removable, having the same VG span
>>   both disks may make the permanent disk unusable if the removable one
>>   is gone.
>>
>>   If it is permanent, consider redoing both of them as a RAID level
>>   1, with encryption and LVM on top of that. Be sure to leave a boot
>>   partition on at least one of them.
>>
>> * You said nothing about encryption. That may impact the order in which
>>   you do things.
>
> From what I can gather there's not much point adding new disk to the 
> LVM if I'm going to use the whole disk as one partition so I formatted 
> it ext4 and mount it somewhere in my home directory.
>
> The default netinstaller doesn't seem to make the boot partition big 
> enough as with the vmlinux off the install media then vmlinux.old and 
> new vmlinux the device was out of space if upgrade so had to remove 
> the original kernel gubbins from the install media. At least that 
> seems to be what happened.
> I'll have to understand LVM at some point to see if I can make boot LV 
> bigger.
>

The LVM howto is your friend


https://tldp.org/HOWTO/LVM-HOWTO/


There is a chapter with examples on most things you might want to do, 
along with common tasks.



> mick
>
-- 
a good plan executed right now is often better than a perfect plan executed slowly. George Patton.

[toc] | [prev] | [next] | [standalone]

#229923

On Tuesday, December 22, 2020 1:26:36 PM CET, elvis wrote:
> The LVM howto is your friend

there are also plenty of man pages!

greetings...

[toc] | [prev] | [next] | [standalone]

#229924

On Tuesday, December 22, 2020 10:58:14 PM CET, mick crane wrote:
> You mean like RTFM or something ?

indeed, i had something like this in mind... ;)

agreed, the quality of man pages is not, what it used to be back in the 
day, when i was young, but lvm is old, and hence the man pages provide more 
useful information than some new wannabe fancy software.

just take some time to read all relevant man pages, and even if they turn 
out not to be relevant: you might learn a thing or two.

learn! that's my advice to everyone, not just you. copy and paste is NOT 
the answer! at least not, if you want to understand what you're doing.

a quick look at the man pages got me this:
- pvcreate <partition> to add a partition to a pool of physical volumes
- vgextend <volume group> <physical device> to add a physical device to a 
volume group
- lvextend [options] <volume group> [<partition(s)>] to extend the size of 
a logical volume

that was not so hard.

greetings...

[toc] | [prev] | [next] | [standalone]

#229932

Hello,

On Tue, Dec 22, 2020 at 11:10:20PM +0000, mick crane wrote:
> On 2020-12-22 22:19, Michael wrote:
> >- pvcreate <partition> to add a partition to a pool of physical volumes

[…]

> I have only skimmed reading the fine manual and other things but I'm
> guessing that if the partition is full I'll either need to make it bigger or
> make another one before invoking LVM?

The partition can't be full because LVM works with block devices,
completely owning them. So if you type:

# pvcreate /dev/foo

then /dev/foo better be already empty because whatever is on it
already is going to be trashed¹.

So the expectation is that the block device ("partition") is empty
and unused when you start.

Seeing as you were talking about installing a new drive and then
putting that in LVM, that doesn't sound like it would pose a problem
to you.

Since it is easy to grow LVM things but often trickier to shrink
them, I advise you to start small.

e.g. if you install a drive and it shows up in your OS as /dev/foo
of size 1TB, then:

# pvcreate /dev/foo
# vgcreate myvg /dev/foo

Now you have a volume group called "myvg" with ~1TB (some space
reserved for metadata) available for allocation.

Your temptation at this point may be to create a logical volume that
uses the whole ~1TB, and you can, but unless you actually
immediately need that size of block device it would be best to hold
off.

Say you need 50GiB of scratch space right away. You'd be better off:

# lvcreate -L50g /dev/myvg/scratch
# mkdir /srv/scratch
# mkfs.ext4 /dev/myvg/scratch
# mount /dev/myvg/scratch /srv/scratch

(names and filesystem types to taste)

…because that leaves you plenty of capacity in the myvg volume group
to later create other logical volumes. If you do end up needing to
grow the scratch space you can do it online:

# lvresize -r -L+50g -n /dev/myvg/scratch

If instead you had immediately made your first LV use the entire
capacity and then later found you wanted other LVs, there'd be no
available capacity and you'd have to shrink the scratch one. Some
filesystems can't be shrunk online (need umount). Some filesystems
can't be shrunk at all!

You also should think about what happens with drive failure,
especially if you are thinking of putting multiple drives into a
volume group with no redundancy.

Cheers,
Andy

¹ Yes I am aware that there are various tricks to move an existing
  filesystem directly on a block device into an LVM LV on the same
  block device, but discussion of this seems way above OP's level at
  this time.

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#229935

[Multipart message — attachments visible in raw view] — view raw

On Wed, Dec 23, 2020 at 07:19:36AM +0000, mick crane wrote:
> On 2020-12-23 03:37, Andy Smith wrote:
> <..>
> >e.g. if you install a drive and it shows up in your OS as /dev/foo
> >of size 1TB, then:
> >
> ># pvcreate /dev/foo
> ># vgcreate myvg /dev/foo
> >
> >Now you have a volume group called "myvg" with ~1TB (some space
> >reserved for metadata) available for allocation.
> 
> This might be where I have gotten confused as online tutorial
> indicates to fdisk the disk first in partitions.
> Make physical volumes of the partitions then create a volume group
> of the partitions.
> You are saying that there is no need to use fdisk to make partitions ?

Not the OP, but basically, that's true.

> Can make Volume Group of raw device eg /dev/sdc after first saying
> it is a Physical Volume ?

Yes.

There are several layers at work here. The lowest (for our current
purposes) is the "block device", which is just an array of equally
sized blocks. This can be a whole "disk" (whatever that [1] may be)
e.g. /dev/sdc. Sometimes you divvy up that disk into partitions,
then you have /dev/sdc2 as a block device.

Sometimes you layer a LUKS device on that, to make sure the stuff
ends up encrypted, to protect your data at rest. The LUKS subsystem
sees that the decrypted data appears as a block device somewhere
(for my laptop one of them is is /dev/dm-4, with a more readable
symlink /dev/mapper/trotzki-home pointing to it).

Sometimes you want to bundle a bunch of block devices to make one
(bigger, more failsafe, perhaps faster, whatever) group of things.

You can stack several of those things. For example, on my laptop,
there's a encrypted container (with LUKS), on top of which I divvy
that up with LVM (I like having separate partitions for things,
but I also like to shift around storage between them should I
have painted myself into a corner. LVM helps with that).

A regular file in your file system can be "made" into a block
device with the help of a "loopback device".
On top of that tower, you make a file system (what you call "format",
which is an unfortunate term here, because it's too broad. As
other things we inherited from DOS).

The commands to make filesystems (e.g. mkfs.ext4 for an Ext 4 file
system) all take one of those block devices as obtained above.
It is the last step in the tower.

Cheers

[1] Disk is a metaphor. Sometimes, there's actually spinning
   rust inside; sometimes something else.

 - t

[toc] | [prev] | [next] | [standalone]

#229925

On 23/12/20 7:58 am, mick crane wrote:
> On 2020-12-22 21:04, Michael wrote:
>> On Tuesday, December 22, 2020 1:26:36 PM CET, elvis wrote:
>>> The LVM howto is your friend
>>
>> there are also plenty of man pages!
>>
>> greetings...
>
> You mean like RTFM or something ?
> The man pages generally assume you know why you are reading them.
> I've noticed a lot of documentation misses out the " You'll want to 
> use this because.."


It's a howto, not a man page so there is a lot more context in it. I was 
pointing it out as an excellent resource.

I find LVM is something I use just infrequently enough that I need to 
look up options when I use it.


>
> mick

-- 
We're going to need a bigger boat

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web