[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANejiEVqPVJ_Rcx60287ypgJg0CBTqX+ozQR-y3jK=UY+SosXg@mail.gmail.com>
Date: Thu, 22 Mar 2012 10:33:50 +0800
From: Shaohua Li <shli@...nel.org>
To: "Martin K. Petersen" <martin.petersen@...cle.com>
Cc: Vivek Goyal <vgoyal@...hat.com>, linux-kernel@...r.kernel.org,
linux-raid@...r.kernel.org, neilb@...e.de, axboe@...nel.dk
Subject: Re: [patch v2 2/6] blk: dont allow discard request merge temporarily
2012/3/22 Martin K. Petersen <martin.petersen@...cle.com>:
>>>>>> "Shaohua" == Shaohua Li <shli@...nel.org> writes:
>
> Shaohua> Enabling discard merge is required for device with slow discard
> Shaohua> (and very helpful for raid),
>
> Before RAID support there really wasn't much point. That's one of the
> reasons the current discard merge code has survived despite being
> completely broken.
Exactly.
> As for how I'd like to handle contiguous discard merges going forward
> here's a proof of concept. It's on top of my write same tree so you may
> have to noodle a bit.
>
> It is crucially important that we never merge a command that can't be
> processed by the device. So I'd like to do something like this:
This is great to consolidate the check with this patch. But looks this
isn't enough. As far as I know the current discard merge is broken
because blk_update_request() can't handle such request because
we override the first BIO to add payload. I had a quick hack and post
out yesterday. It works in my SATA ssd, but I really didn't know if there
is something missing in SCSI side, can you share anything here?
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/
Powered by blists - more mailing lists