DST update

January 19, 2009 zbr Uncategorized

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 BUG_ON() in 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.

DST

New POHMELFS vs NFS vs DST benchmarks NFS/credentials leak in 2.6.29-rc1 and thoughts on NFS performance