From: Zdenek Kabelac <zkabelac@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: Christoph Anton Mitterer <calestyo@scientia.net>
Subject: Re: [linux-lvm] some questions
Date: Fri, 19 Jul 2013 21:52:37 +0200 [thread overview]
Message-ID: <51E99905.9000508@redhat.com> (raw)
In-Reply-To: <1374258168.5231.48.camel@fermat.scientia.net>
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
next prev parent reply other threads:[~2013-07-19 19:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-18 18:43 [linux-lvm] some questions Christoph Anton Mitterer
2013-07-19 10:36 ` Zdenek Kabelac
2013-07-19 18:22 ` Christoph Anton Mitterer
2013-07-19 19:52 ` Zdenek Kabelac [this message]
2013-07-19 23:01 ` Christoph Anton Mitterer
-- strict thread matches above, loose matches on Subject: below --
2007-07-02 19:03 Andrés Ghigliazza
2007-07-02 20:24 ` Richard van den Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51E99905.9000508@redhat.com \
--to=zkabelac@redhat.com \
--cc=calestyo@scientia.net \
--cc=linux-lvm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.