aborted SCSI commands while discarding/unmapping via mkfs.xfs
Stefan Priebe - Profihost AG
s.priebe at profihost.ag
Wed Aug 15 01:31:14 CDT 2012
Am 14.08.2012 23:35, schrieb Dave Chinner:
> On Tue, Aug 14, 2012 at 10:42:21PM +0200, Stefan Priebe wrote:
>> Hello list,
>>
>> i'm testing KVM with qemu, libiscsi, virtio-scsi-pci and
>> scsi-general on top of a nexenta storage solution. While doing
>> mkfs.xfs on an already used LUN / block device i discovered that the
>> unmapping / discard commands mkfs.xfs sends take a long time which
>> results in a lot of aborted scsi commands.
>
> Sounds like a problem with your storage being really slow at
> discards.
>
>> Would it make sense to let mkfs.xfs send these unmapping commands in
>> small portations (f.e. 100MB)
>
> No, because the underlying implementation (blkdev_issue_discard())
> already breaks the discard request up into the granularity that is
> supported by the underlying storage.....
>
>> or is there another problem in the
>> patch to the block device? Any suggestions or ideas?
>
> .... which, of course, had bugs in it so is a muchmore likely cause
> of your problems.
>
> That said,the discard granularity is derived from information the
> storage supplies the kernel in it's SCSI mode page, so if the
> discard granularity is too large, that's a storage problem, not a
> linux problem at all, let alone a mkfs.xfs problem.
Thanks for this excelent explanation.
Stefan
More information about the xfs
mailing list