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: <CANejiEXP9ORKTfE4O9khaHSp-Y8yOQU1LLUD5Q5pBJOGR+A-aA@mail.gmail.com>
Date:	Wed, 14 Mar 2012 19:14:30 +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 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.

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/