Hi there,
I was just testing discard support in mke2fs, and I was surprised that
although the dm layer appears to pass discard requests through to the
underlying block device driver when submitted through the bio layer
(i.e., from kernel file systems), apparently the discard ioctls (i.e.,
BLKDISCARD, BLKDISCARDSEC, BLKDISCARDZEROES) are not currently wired up
in the dm layer.
Is this deliberate, or an oversight?
Thanks, regards,
- Ted
Hi Ted,
On Mon, Sep 20 2010 at 9:14am -0400,
Theodore Ts'o <[email protected]> wrote:
> Hi there,
>
> I was just testing discard support in mke2fs, and I was surprised that
> although the dm layer appears to pass discard requests through to the
> underlying block device driver when submitted through the bio layer
> (i.e., from kernel file systems), apparently the discard ioctls (i.e.,
> BLKDISCARD, BLKDISCARDSEC, BLKDISCARDZEROES) are not currently wired up
> in the dm layer.
After enabling scsi tracing:
# mount -t debugfs none /sys/kernel/debug
# cd /sys/kernel/debug/tracing/
# echo "scsi:*" > set_event
# cat trace_pipe
I'm not seeing a problem with BLKDISCARD (via mkfs.ext4) for either
request-based DM (this is on a 2.6.36-rc4 kernel w/ the FLUSH+FUA patchset):
kworker/0:1-21 [000] 6046573.148416: scsi_dispatch_cmd_start: host_no=3 channel=0 id=0 lun=0 data_sgl=1 prot_sgl=0 cmnd=(UNMAP regions=1 raw=42 00 00 00 00 00
00 00 18 00)
<idle>-0 [000] 6046573.152001: scsi_dispatch_cmd_done: host_no=3 channel=0 id=0 lun=0 data_sgl=1 prot_sgl=0 cmnd=(UNMAP regions=1 raw=42 00 00 00 00 00 00 00 18 00) result=(driver=DRIVER_OK host=DID_OK message=COMMAND_COMPLETE status=SAM_STAT_GOOD)
...
or bio-based DM:
kworker/0:1-21 [000] 6046158.384097: scsi_dispatch_cmd_start: host_no=2 channel=0 id=0 lun=0 data_sgl=1 prot_sgl=0 cmnd=(UNMAP regions=1 raw=42 00 00 00 00 00
00 00 18 00)
<idle>-0 [000] 6046158.405034: scsi_dispatch_cmd_done: host_no=2 channel=0 id=0 lun=0 data_sgl=1 prot_sgl=0 cmnd=(UNMAP regions=1 raw=42 00 00 00 00 00 00 00 18 00) result=(driver=DRIVER_OK host=DID_OK message=COMMAND_COMPLETE status=SAM_STAT_GOOD)
...
> Is this deliberate, or an oversight?
DM should implicitly supports the BLKDISCARD* ioctls -- just like any
other block device ioctl.
Mike
On Mon, Sep 20 2010 at 1:40pm -0400,
Mike Snitzer <[email protected]> wrote:
> Hi Ted,
>
> On Mon, Sep 20 2010 at 9:14am -0400,
> Theodore Ts'o <[email protected]> wrote:
>
> > Hi there,
> >
> > I was just testing discard support in mke2fs, and I was surprised that
> > although the dm layer appears to pass discard requests through to the
> > underlying block device driver when submitted through the bio layer
> > (i.e., from kernel file systems), apparently the discard ioctls (i.e.,
> > BLKDISCARD, BLKDISCARDSEC, BLKDISCARDZEROES) are not currently wired up
> > in the dm layer.
>
> After enabling scsi tracing:
> # mount -t debugfs none /sys/kernel/debug
> # cd /sys/kernel/debug/tracing/
> # echo "scsi:*" > set_event
> # cat trace_pipe
>
> I'm not seeing a problem with BLKDISCARD (via mkfs.ext4) for either
> request-based DM (this is on a 2.6.36-rc4 kernel w/ the FLUSH+FUA patchset):
Here is a trace during mkfs.ext4 of a bio-based striped DM device (with
4 stripes) on a stock 2.6.36-rc4:
mkfs.ext4-3835 [000] 6050624.201765: scsi_dispatch_cmd_start: host_no=10 channel=0 id=0 lun=0 data_sgl=1 prot_sgl=0 cmnd=(UNMAP regions=1 raw=42 00 00 00 00 00 00 00 18 00)
mkfs.ext4-3835 [000] 6050624.201790: scsi_dispatch_cmd_start: host_no=10 channel=0 id=0 lun=0 data_sgl=1 prot_sgl=0 cmnd=(UNMAP regions=1 raw=42 00 00 00 00 00 00 00 18 00)
mkfs.ext4-3835 [000] 6050624.201806: scsi_dispatch_cmd_start: host_no=10 channel=0 id=0 lun=0 data_sgl=1 prot_sgl=0 cmnd=(UNMAP regions=1 raw=42 00 00 00 00 00 00 00 18 00)
mkfs.ext4-3835 [000] 6050624.201823: scsi_dispatch_cmd_start: host_no=10 channel=0 id=0 lun=0 data_sgl=1 prot_sgl=0 cmnd=(UNMAP regions=1 raw=42 00 00 00 00 00 00 00 18 00)
<idle>-0 [000] 6050624.202772: scsi_dispatch_cmd_done: host_no=10 channel=0 id=0 lun=0 data_sgl=1 prot_sgl=0 cmnd=(UNMAP regions=1 raw=42 00 00 00 00 00 00 00 18 00) result=(driver=DRIVER_OK host=DID_OK message=COMMAND_COMPLETE status=SAM_STAT_GOOD)
<idle>-0 [000] 6050624.202774: scsi_dispatch_cmd_done: host_no=10 channel=0 id=0 lun=0 data_sgl=1 prot_sgl=0 cmnd=(UNMAP regions=1 raw=42 00 00 00 00 00 00 00 18 00) result=(driver=DRIVER_OK host=DID_OK message=COMMAND_COMPLETE status=SAM_STAT_GOOD)
<idle>-0 [000] 6050624.202775: scsi_dispatch_cmd_done: host_no=10 channel=0 id=0 lun=0 data_sgl=1 prot_sgl=0 cmnd=(UNMAP regions=1 raw=42 00 00 00 00 00 00 00 18 00) result=(driver=DRIVER_OK host=DID_OK message=COMMAND_COMPLETE status=SAM_STAT_GOOD)
<idle>-0 [000] 6050624.202775: scsi_dispatch_cmd_done: host_no=10 channel=0 id=0 lun=0 data_sgl=1 prot_sgl=0 cmnd=(UNMAP regions=1 raw=42 00 00 00 00 00 00 00 18 00) result=(driver=DRIVER_OK host=DID_OK message=COMMAND_COMPLETE status=SAM_STAT_GOOD)
On Mon, 20 Sep 2010, Theodore Ts'o wrote:
> Hi there,
>
> I was just testing discard support in mke2fs, and I was surprised that
> although the dm layer appears to pass discard requests through to the
> underlying block device driver when submitted through the bio layer
> (i.e., from kernel file systems), apparently the discard ioctls (i.e.,
> BLKDISCARD, BLKDISCARDSEC, BLKDISCARDZEROES) are not currently wired up
> in the dm layer.
>
> Is this deliberate, or an oversight?
>
> Thanks, regards,
Hi Ted,
I have tested this with 2.6.35 and it really did not work for me as
well, but with 2.6.36-rc5 (latests kernel) it works just fine. Though,
not sure when it was added. But according to the log it seems it was
merged in with 8357422d4bf33bc2c35884d4016c3fc9efbbc1d2.
-Lukas
>
> - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Tue, Sep 21, 2010 at 6:42 AM, Lukas Czerner <[email protected]> wrote:
> On Mon, 20 Sep 2010, Theodore Ts'o wrote:
>
>> Hi there,
>>
>> I was just testing discard support in mke2fs, and I was surprised that
>> although the dm layer appears to pass discard requests through to the
>> underlying block device driver when submitted through the bio layer
>> (i.e., from kernel file systems), apparently the discard ioctls (i.e.,
>> BLKDISCARD, BLKDISCARDSEC, BLKDISCARDZEROES) are not currently wired up
>> in the dm layer.
>>
>> Is this deliberate, or an oversight?
>>
>> Thanks, regards,
>
> Hi Ted,
>
> I have tested this with 2.6.35 and it really did not work for me as
> well, but with 2.6.36-rc5 (latests kernel) it works just fine. Though,
> not sure when it was added. But according to the log it seems it was
> merged in with 8357422d4bf33bc2c35884d4016c3fc9efbbc1d2.
Makes sense, DM's discard support was added during the 2.6.36 merge window.
Mike