I updated the DST and pushed it ‘upstream’ (into drivers/staging). Besides bio allocation optimization suggested by Jens Axboe, update fixes an interesting bug I started to observe recently between DST and the block layer
kernel BUG at drivers/scsi/scsi_lib.c:1310! EIP is at scsi_setup_fs_cmnd+0x37/0x6c [scsi_mod] Call Trace: [
] sd_prep_fn+0x61/0x792 [sd_mod] [ ] __cfq_slice_expired+0x57/0x62 [ ] elv_next_request+0xa8/0x14c [ ] scsi_request_fn+0x6c/0x3f5 [scsi_mod]
This is a
scsi_setup_fs_cmnd(), which fires when there are no data segments attached to the block IO. This may be empty barrier or recently added data discard request though.
First I thought it is somehow related to the fact, that I recently swiched DST request queue initialization from plain and dumb allocation to the more advanced
blk_init_queue(), although I do not use its features. Something like request queue issues a final barrier. Reverting the change did not fix the problem.
So I lazily googled and found 51fd77bd9f512ab6 commit, which disables empty barriers (by completing bio with
-EOPNOTSUPP error). This code was changed to only disable bios which have data discard request and no flush prepare function. I used the same logic in DST and still got the same bug. After I enabled the log, I found that XFS issued a final barrier at the umount time without attached data. I used the same logic as in 51fd77bd9f512ab6 commit, i.e. completing bio with
-EOPNOTSUPP error, but XFS froze the system. Oops, I really do not know XFS at all, but succesfully completing bio (with 0 error) fixed the issue. Weird.