BIO_FLUSH, drive write cache: Which drivers do the Right Thing?

Jan Mikkelsen janm at transactionware.com
Mon Aug 7 09:16:06 UTC 2017


Hi,

I'm looking at how ZFS interacts with drive-based write caches, so that I can work out what is “safe”.

The premise is that drive write caching is safe because ZFS can flush the drive write cache when necessary to ensure updates get to the physical media in the correct order. For this to work, the actual command has to get to the drive.

This seems to work for ata(4), da(4) and amr(4).

Other non-CAM RAID controllers, eg. mfi(4) don’t seem to support this at all, including for JBOD drives like mfisyspd.

For CAM-based controllers (eg. mpr(4) or mrsas(4)), it seems that controllers like mpr(4) pass the SCSI command on as expected. RAID controllers implementing CAM have to do the right thing to make it work; mrsas(4) seems to find SYNCHRONIZE_CACHE and do something but I’m not sure that it really sending a cache flush command to any underlying drives.

From all of this, this is what I see:

- ata(4) and amr(4) pass the flush command to the drive, allowing the use of drive write cache.

- da(4) on “plain SCSI” controllers pass the command to the drive, allowing the use of drive write cache.

- da(4) for RAID controllers may or may not get the command to the drives.

- Other RAID controllers will not currently get the command to the underlying drives, making drive write cache dangerous.

Some questions:

Does mrsas(4) really get a write cache flush to the drive? Does it vary for the JBOD and RAID volume case?

Is all this correct? What have I missed?

Thanks,

Jan Mikkesen






More information about the freebsd-scsi mailing list