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


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

SSD TRIM software raid (mdadm)

Started bybasti <mailinglist@unix-solution.de>
First post2019-01-09 22:30 +0100
Last post2019-01-10 03:50 +0100
Articles 4 — 3 participants

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


Contents

  SSD TRIM software raid (mdadm) basti <mailinglist@unix-solution.de> - 2019-01-09 22:30 +0100
    Re: SSD TRIM software raid (mdadm) Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-01-10 01:00 +0100
      Re: SSD TRIM software raid (mdadm) basti <mailinglist@unix-solution.de> - 2019-01-10 10:50 +0100
    Re: SSD TRIM software raid (mdadm) David Christensen <dpchrist@holgerdanske.com> - 2019-01-10 03:50 +0100

#204264 — SSD TRIM software raid (mdadm)

Frombasti <mailinglist@unix-solution.de>
Date2019-01-09 22:30 +0100
SubjectSSD TRIM software raid (mdadm)
Message-ID<xetAd-7lH-5@gated-at.bofh.it>
Hello,
I have create a software raid level 1 with mdadm.

One drive is a "classic" HDD.
The 2'nd drive is a SSD with option "write-mostly".

Over the raid I have create and LVM with all the partitions (root,swap
and qemu/KVM VM's).

When I understand mdadm the hole space is marked as used.
So my question is how useful is fstrim on /dev/mdx and would it relay
trim the SSD?

Best Regards,

[toc] | [next] | [standalone]


#204273

FromPascal Hambourg <pascal@plouf.fr.eu.org>
Date2019-01-10 01:00 +0100
Message-ID<xevVn-eX-11@gated-at.bofh.it>
In reply to#204264
Le 09/01/2019 à 22:22, basti a écrit :
> I have create a software raid level 1 with mdadm.
> 
> One drive is a "classic" HDD.
> The 2'nd drive is a SSD with option "write-mostly".

Why did you flag the SSD as write-mostly ? I would have expected the 
opposite.

> Over the raid I have create and LVM with all the partitions (root,swap
> and qemu/KVM VM's).
> 
> When I understand mdadm the hole space is marked as used.

I don't understand what you mean.

> So my question is how useful is fstrim on /dev/mdx and would it relay
> trim the SSD?

RAID 1 supports TRIM since kernel 3.7. Since the HDD does not support 
TRIM, it will make discarded bloc contents inconsistent between the SSD 
and the HDD but it does not matter.

However you wrote that the RAID device is used by LVM, so you cannot run 
fstrim on it directly. You must enable TRIM/discard in LVM (see 
lvm.conf) and run fstrim on LVs which contain mounted filesystems 
supporting TRIM/discard.

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


#204286

Frombasti <mailinglist@unix-solution.de>
Date2019-01-10 10:50 +0100
Message-ID<xeF8m-5Yd-15@gated-at.bofh.it>
In reply to#204273
On 10.01.19 00:51, Pascal Hambourg wrote:
> Why did you flag the SSD as write-mostly ? I would have expected the
> opposite.

Oh Sorry I understand this option in a wrong way.
Ok, I will try TRIM on LVM.

Thanks a lot.

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


#204278

FromDavid Christensen <dpchrist@holgerdanske.com>
Date2019-01-10 03:50 +0100
Message-ID<xeyzT-1Rs-1@gated-at.bofh.it>
In reply to#204264
On 1/9/19 1:22 PM, basti wrote:
> Hello, I have create a software raid level 1 with mdadm.
> 
> One drive is a "classic" HDD. The 2'nd drive is a SSD with option 
> "write-mostly".
> 
> Over the raid I have create and LVM with all the partitions 
> (root,swap and qemu/KVM VM's).
> 
> When I understand mdadm the hole space is marked as used. So my 
> question is how useful is fstrim on /dev/mdx and would it relay trim 
> the SSD?
> 
> Best Regards,

On 1/9/19 3:51 PM, Pascal Hambourg wrote:
> Why did you flag the SSD as write-mostly ? I would have expected the 
> opposite.

+1  RTFM mdadm(8), --write-mostly would make more sense on the HDD.


But, one SSD and one HDD in an MD mirror seems strange.  If mirroring is 
not required, I would:

1.  Partition the SSD with boot, swap, root, and VM partitions.  Give 
each VM a small virtual drive image file for its system drive.

2.  Put one large partition on the HDD.  Give each VM a virtual drive 
image file, sized as required, for its data drive.


If you can install an additional SSD, mirror the two SSD's.  Similarly 
so for an additional HDD.


In any case:

1.  Try to characterize your I/O workload -- synchronous vs. 
asynchronous, read vs. write, sequential vs. random, small vs. large.

2.  Configure things to use asynchronous I/O, where possible.

3.  Install plenty of RAM.

4.  Try multiple configurations and benchmark each, preferably with 
realistic workloads.


David

[toc] | [prev] | [standalone]


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


csiph-web