Is it deliberate that the device mapper is not passing the DISCARD ioctls

Is it deliberate that the device mapper is not passing the DISCARD ioctls

[Theodore Ts'o]

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

Re: Is it deliberate that the device mapper is not passing the DISCARD ioctls

[Mike Snitzer]

Hi Ted,

On Mon, Sep 20 2010 at  9:14am -0400,
Theodore Ts'o <tytso@mit.edu> 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

Re: Is it deliberate that the device mapper is not passing the DISCARD ioctls

[Mike Snitzer]

On Mon, Sep 20 2010 at  1:40pm -0400,
Mike Snitzer <snitzer@redhat.com> wrote:

> Hi Ted,
> 
> On Mon, Sep 20 2010 at  9:14am -0400,
> Theodore Ts'o <tytso@mit.edu> 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)

Re: Is it deliberate that the device mapper is not passing the DISCARD ioctls

[Lukas Czerner]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Is it deliberate that the device mapper is not passing the DISCARD ioctls

[Mike Snitzer]

On Tue, Sep 21, 2010 at 6:42 AM, Lukas Czerner <lczerner@redhat.com> 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