[linux-lvm] some questions

[linux-lvm] some questions

[Andrés Ghigliazza]

Hi there,

I have some questions:

- In http://www.tldp.org/HOWTO/LVM-HOWTO/, there is a guide to convert
a root filesystem to LVM1 (13.8). Is there any guide to convert a root
filesystem to LVM2?

- It is LVM2 stable enough?, or by now, and for a production system,
is preferable LVM1?

- Several times, I had to recover data from hard disks without LVM; in
those cases, I boot with a live GNU/Linux CD, mount the partitions,
and copy the files. Can this be done with disks with LVM?, how?, which
live CD do you recommend for this task?.

Thanks very much,

tizo

Re: [linux-lvm] some questions

[Richard van den Berg]

Andr�s Ghigliazza wrote:
> - Several times, I had to recover data from hard disks without LVM; in
> those cases, I boot with a live GNU/Linux CD, mount the partitions,
> and copy the files. Can this be done with disks with LVM?, how?, which
> live CD do you recommend for this task?.

Personally I recommend systemrescuecd from http://www.sysresccd.org/ It
comes with lvm2 and all other tools I've ever needed to recover a system.

Sincerely,

Richard van den Berg

[linux-lvm] some questions

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]

Hi.

I'd have some questions...

1) Is the --discards option the same than the issue_discards option from
the config file? Since the one defaults to 0 the other to passdown?
If not what's the difference?


2) Of an existing LV, can I see how data was actually allocated? And how
can I see the alloc policy of a VG? vgdisplay doesn't show it.


3) Do I see that correctly, when I use Normal as alloc policy,... it
will try to do contiguous allocation... and only do not so,... if not
possible?


4) md_component_detection and md_chunk_alignment
Will these also work if there is another block layer (e.g. dmcrypt) in
between? Especially the md_chunk_alignment?


5) What alignments are needed?
"md_chunk_alignment — If set to 1, and a Physical Volume is placed
directly upon an md device, LVM2 will align its data blocks with the md
device's stripe-width."

Implies that something needs to be aligned to the strip width (I guess
you mean the chunk_size * number_of_data_chunks (i.e. not counting
parity)?)?
What is that? Should the PEs be aligned to the stripe width? I.e.
multiple PEs exactly in one stripe, or multiple stripes exactly in one
PE?


Thanks,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5165 bytes --]

Re: [linux-lvm] some questions

[Zdenek Kabelac]

Dne 18.7.2013 20:43, Christoph Anton Mitterer napsal(a):
> Hi.
>
> I'd have some questions...
>
> 1) Is the --discards option the same than the issue_discards option from
> the config file? Since the one defaults to 0 the other to passdown?
> If not what's the difference?

Nope

--discards options is for thin volume in thin pool - while lvm.conf option is 
about discarding free space in VG - in general - unless you are using some
virtual storage for PVs - it's not a wise idea to enable  issue_discards,
since it makes recovery (i.e. going one step back) impossible - what is 
discarded cannot be recovered...

For thin volumes - it could be used to free already provisioned space from 
pool (as well as getting native discard on SSD if the pool is on SSD).
Behaviour is configurable.


> 2) Of an existing LV, can I see how data was actually allocated? And how
> can I see the alloc policy of a VG? vgdisplay doesn't show it.

Looks like this attribute should be added to  lvs/vgs.
For now only  lvdisplay shows allocation policy for LV.
To see allocated extents you could use:

lvs -o+seg_pe_ranges


> 3) Do I see that correctly, when I use Normal as alloc policy,... it
> will try to do contiguous allocation... and only do not so,... if not
> possible?

Yes


> 4) md_component_detection and md_chunk_alignment
> Will these also work if there is another block layer (e.g. dmcrypt) in
> between? Especially the md_chunk_alignment?

it's only one-layer check - there is no device stack analysis.

> 5) What alignments are needed?
> "md_chunk_alignment � If set to 1, and a Physical Volume is placed
> directly upon an md device, LVM2 will align its data blocks with the md
> device's stripe-width."

What is visible in sysfs  is used.
It's responsibility of each device to provide correct values for alignment.
i.e. if you have crypted  mdraid device - then crypto needs to export
right values.

Zdenek

Re: [linux-lvm] some questions

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 2066 bytes --]

On Fri, 2013-07-19 at 12:36 +0200, Zdenek Kabelac wrote:
> --discards options is for thin volume in thin pool
Is that then really only for thin pools?
I mean not when I "free" the LEs by removing/shrinking an LV, but when
e.g. my ext4 deletes a file and sends a discard... does LVM pass that on
and is that generally affected by --discards?

E.g. in cryptsetup you have a general option which controls whether TRIM
is passed through dm-crypt to lower block layers... I though --discards
of being like that...


>  - while lvm.conf option is 
> about discarding free space in VG - in general - unless you are using some
> virtual storage for PVs - it's not a wise idea to enable  issue_discards,
> since it makes recovery (i.e. going one step back) impossible - what is 
> discarded cannot be recovered...
Sure... when e.g. using dmcrypt with it would have even some security
drawbacks...


> lvs -o+seg_pe_ranges
Ah... that one was exactly what I've been looking for :)
Thx :)


> > 5) What alignments are needed?
> > "md_chunk_alignment — If set to 1, and a Physical Volume is placed
> > directly upon an md device, LVM2 will align its data blocks with the md
> > device's stripe-width."
> What is visible in sysfs  is used.
> It's responsibility of each device to provide correct values for alignment.
> i.e. if you have crypted  mdraid device - then crypto needs to export
> right values.
What I mean is... what needs to be aligned to the stripe-with?

I though it would be enough if the dataalignment offset of the PVs was
correctly to the underlying "blocks". AFAIU they even wouldn't need to
be aligned to the chunksize of the MD, since the only blocks valid for
MD are the ones from the physical drive below (usually 512B or 4KiB) and
in case of striped MD, PAGE_SIZE blocks (usually 4KiB as well) in which
MD reads/writes parity.

Does LVM recommend that the PE's (i.e. the 4 MiB - not KiB) are aligned
to the stripe size? I though the PE size is irrelevant for normal
reads/writes...


Thanks,
Chris.



[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5113 bytes --]

Re: [linux-lvm] some questions

[Zdenek Kabelac]

Dne 19.7.2013 20:22, Christoph Anton Mitterer napsal(a):
> On Fri, 2013-07-19 at 12:36 +0200, Zdenek Kabelac wrote:
>> --discards options is for thin volume in thin pool
> Is that then really only for thin pools?
> I mean not when I "free" the LEs by removing/shrinking an LV, but when
> e.g. my ext4 deletes a file and sends a discard... does LVM pass that on
> and is that generally affected by --discards?
>
> E.g. in cryptsetup you have a general option which controls whether TRIM
> is passed through dm-crypt to lower block layers... I though --discards
> of being like that...

By default every normal (i.e. linear) LV should pass-through discards - there 
is AFAICS no code to block them and you can't disable them.

For thin volume - it's going through the pool first - and you have the choice
either to ignore them completely, process them at pool level or pass-through 
the pool to pool data device.


>>   - while lvm.conf option is
>> about discarding free space in VG - in general - unless you are using some
>> virtual storage for PVs - it's not a wise idea to enable  issue_discards,
>> since it makes recovery (i.e. going one step back) impossible - what is
>> discarded cannot be recovered...
> Sure... when e.g. using dmcrypt with it would have even some security
> drawbacks...

dmcrypt is not a problem here - but when you i.e. lvreduce -  then if 
'issue_discard' is enabled - then you cannot revert/vgcfgrestore this
metadata operation - since all reduced data would have been discarded.

In general - whenever you create new LV and then you use mkfs - it will 
discard whole device anyway.

> I though it would be enough if the dataalignment offset of the PVs was
> correctly to the underlying "blocks". AFAIU they even wouldn't need to
> be aligned to the chunksize of the MD, since the only blocks valid for
> MD are the ones from the physical drive below (usually 512B or 4KiB) and
> in case of striped MD, PAGE_SIZE blocks (usually 4KiB as well) in which
> MD reads/writes parity.
>
> Does LVM recommend that the PE's (i.e. the 4 MiB - not KiB) are aligned
> to the stripe size? I though the PE size is irrelevant for normal
> reads/writes...


Initial extents should be aligned (and ideally all extents) - (lvm2 metadata 
are located in front of extents)

i.e. my SSD uses 512KiB blocks - so this is the minimal alignment.
it's not always simple to decide which type of striping is ideal.


Zdenek

Re: [linux-lvm] some questions

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

Hi.


On Fri, 2013-07-19 at 21:52 +0200, Zdenek Kabelac wrote:
> > E.g. in cryptsetup you have a general option which controls whether TRIM
> > is passed through dm-crypt to lower block layers... I though --discards
> > of being like that...
> 
> By default every normal (i.e. linear) LV should pass-through discards - there 
> is AFAICS no code to block them and you can't disable them.
> 
> For thin volume - it's going through the pool first - and you have the choice
> either to ignore them completely, process them at pool level or pass-through 
> the pool to pool data device.
Can you add that to the description of --discard in the manpage?

I think right now one might easily think that it's a general control, on
whether LVM passes these through or not.


Thanks,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5113 bytes --]