linux-kernel - Re: [patch 0/7] 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: <CANejiEXnYpKx741LDs9SzrQKKpfmguO2WFkzWemtiMPtZH0ODA@mail.gmail.com>
Date:	Wed, 14 Mar 2012 19:32:49 +0800
From:	Shaohua Li <shli@...nel.org>
To:	Holger Kiehl <Holger.Kiehl@....de>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-raid@...r.kernel.org" <linux-raid@...r.kernel.org>,
	"neilb@...e.de" <neilb@...e.de>,
	"axboe@...nel.dk" <axboe@...nel.dk>
Subject: Re: [patch 0/7] Add TRIM support for raid linear/0/1/10

2012/3/14 Shaohua Li <shli@...nel.org>:
> 2012/3/14 Holger Kiehl <Holger.Kiehl@....de>:
>> On Wed, 14 Mar 2012, Shaohua Li wrote:
>>
>>> 2012/3/13 Holger Kiehl <Holger.Kiehl@....de>:
>>>>
>>>> On Tue, 13 Mar 2012, Shaohua Li wrote:
>>>>
>>>>> Thanks for testing. This is very wield, the req->__data_len is wrong.
>>>>> Is this a clean build?
>>>>>
>>>> I just downloaded linux-3.3-rc7.tar.bz2 from kernel.org and applied
>>>> your patches again. The result is the same.
>>>>
>>>> Am I the only one experiencing these problems?
>>>
>>> Martin Petersen pointed out scsi layer doesn't support discard merge,
>>> which
>>> might be the reason you see the error message (my drive isn't a scsi
>>> device).
>>> can you please try attached patch?
>>>
>> Thanks! After this patch the error messages are away.
>>
>> However, when the system boots it takes a very long time to boot:
>>
>>   [   16.527389] EXT4-fs (md0): mounted filesystem with ordered data mode.
>> Opts: discard,commit=2400,journal_async_commit
>>   [   24.218410] EXT4-fs (md2): mounted filesystem with ordered data mode.
>> Opts: discard,commit=600,journal_async_commit
>>   [   69.823138] udevd[474]: timeout '/sbin/blkid -o udev -p /dev/md0'
>>   [   70.824197] udevd[474]: timeout: killing '/sbin/blkid -o udev -p
>> /dev/md0' [866]
>>   [   70.826823] udevd[474]: '/sbin/blkid -o udev -p /dev/md0' [866]
>> terminated by signal 9 (Killed)
>>   [   70.829290] udevd[474]: timeout 'udisks-part-id /dev/md0'
>>   [   74.942625] udevd[475]: timeout '/sbin/blkid -o udev -p /dev/md2'
>>   [   75.947158] udevd[475]: timeout: killing '/sbin/blkid -o udev -p
>> /dev/md2' [874]
>>   [   75.949734] udevd[475]: '/sbin/blkid -o udev -p /dev/md2' [874]
>> terminated by signal 9 (Killed)
>>   [   75.951945] udevd[475]: timeout 'udisks-part-id /dev/md2'
>>   [   79.023741] rmmod[886]: ERROR: Module scsi_wait_scan does not exist in
>> /proc/modules
>>   [   96.005919] systemd[1]: dev-md3.swap activation timed out. Stopping.
>>   [  127.292002] Adding 9434108k swap on /dev/md3.  Priority:0 extents:1
>> across:9434108k
>>
>> During another boot I saw this additional message:
>>
>>   [   11.988732] scsi_verify_blk_ioctl: 930 callbacks suppressed
>>
>> The strange thing is that after boot I tried to enter the command
>> '/sbin/blkid -o udev -p /dev/md0' and it works without any problems
>> (time for this is 0m0.001s). So I also tried booting without discard
>> option, but the result is the same.
>>
>> Otherwise I observed no problems. Even running some more extensive
>> benchmark testing showed no problems. Only the performance drop is
>> dramatic. In my own benchmark where thousand of files get copied around
>> via FTP the performance drops from 4000 files per second to 520 when
>> mounting the filesystem with discard option. Also during the benchmark
>> any access to the disk can take very very long if discard is enabled.
>>
>> Next, I will try this patch on a system without SATA/SCSI disks.
> Maybe the discard runs slow with small size request in the disk.
> please drop patch "blk: add plug for blkdev_issue_discard" and try again. Since
> we can't do merge, the plug just introduces latency.
> if it doesn't help, please capture a blktrace when you do the benchmark and
> send it to me.
Is it possible if you can directly build a fs in such ssd (that is not
using raid), and check
the performance of discard? I'd like to make sure it's not the problem
of the ssd itself.
the raid chunk size is 512k, which is already big even without merge.

Thanks,
Shaohua
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/