linux-kernel - Re: [patch v2 0/6] Add TRIM support for raid linear/0/1/10

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LRH.2.02.1203200839120.29880@diagnostix.dwd.de>
Date:	Tue, 20 Mar 2012 09:50:08 +0000 (GMT)
From:	Holger Kiehl <Holger.Kiehl@....de>
To:	Shaohua Li <shli@...nel.org>
cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-raid <linux-raid@...r.kernel.org>, neilb@...e.de,
	axboe@...nel.dk, vgoyal@...hat.com, martin.petersen@...cle.com
Subject: Re: [patch v2 0/6] Add TRIM support for raid linear/0/1/10

Hello,

On Tue, 20 Mar 2012, Shaohua Li wrote:

> 2012/3/20 Holger Kiehl <Holger.Kiehl@....de>:
>> Hello,
>>
>>
>> On Fri, 16 Mar 2012, Shaohua Li wrote:
>>
>>> The patches add TRIM support for raid linear/0/1/10. I'll add TRIM support
>>> for
>>> raid 4/5/6 later. The implementation is pretty straightforward and
>>> self-explained.
>>>
>>> v1->v2:
>>> 1. fixed a checking issue
>>> 2. dropped discard request plug and replace it with no discard merege,
>>> because
>>> current SCSI layer can't handle discard request merge.
>>>
>> Have tested TRIM patches on three different systems with the following
>> hardware/ setup:
>>
>>   1) root mounted on a raid1 over two SAS SSD's (200GB) and /home partition
>>      on a raid0 over a fusionio ioDrive Duo. Is very new and seen very
>>      little usage.
>>
>>   2) root and /home mounted on a raid0 over two Intel X25 Postville
>>      (160GB) connected to a Intel P55 Express chipset. Has seen very
>>      heavy usage for approx. 2 years.
>>
>>   3) root and /home mounted on a raid0 over three OCZ-VERTEX2 (120GB)
>>      connected via ICH7 south bridge. Has seen mild usage for approx.
>>      1.5 years.
>>
>> Made the following observations when running my own benchmark which
>> copies around a lot of small files and deletes them. The benchmark on
>> all systems was always run only on the /home partition ie. on a raid0.
>>
>> For system 1) there is hardly any measurable differnce whether discard
>> is enabled or not (~29000 files per second).
>>
>> On system 2) the performance drops from 6500->3700 files per second,
>> but under normal usage one does not notice any difference.
> do you have the blktrace data when the benchmark is running, especially
> when doing file deletion. I'd like to check the latency of discard in this case.
>
It is uploaded on ftp://ftp.dwd.de/pub/afd/test/trim

>> System 3) has problems during boot, it is so slow that some operations
>> receive a timeout during boot:
>>
>>  udevd[474]: timeout '/sbin/blkid -o udev -p /dev/md0'
>>  udevd[474]: timeout: killing '/sbin/blkid -o udev -p /dev/md0' [866]
>>  systemd[1]: dev-md3.swap activation timed out. Stopping.
> In this one, discard request is slow. And per SATA standard, discard request
> can't be parallel, so only one request one time, which further slows it down.
>
Ok, so having three disc in a raid 0 is even worth.

>> Even removing discard does not help and the above errors happen during
>> boot and booting takes a long time.
> this doesn't make sense. If you don't mount with discard option, no
> discard request
> is issued.
>
I read some where that swap uses discard by default and if I remember
correctly it initializes the whole swap area at boot. So doing that
over three disks might explain why I get those timeout error messages
and after boot these commands work without delay.

Regards,
Holger