Date: Mon, 7 Aug 2017 19:11:18 +1000 From: Jan Mikkelsen <janm@transactionware.com> To: freebsd-scsi@freebsd.org Subject: BIO_FLUSH, drive write cache: Which drivers do the Right Thing? Message-ID: <6E659EED-746D-4936-9C53-702D72DA84B8@transactionware.com>
next in thread | raw e-mail | index | archive | help
Hi, I'm looking at how ZFS interacts with drive-based write caches, so that = I can work out what is =E2=80=9Csafe=E2=80=9D. 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=E2=80=99t 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=E2=80=99m = not sure that it really sending a cache flush command to any underlying = drives. =46rom 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 =E2=80=9Cplain SCSI=E2=80=9D 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6E659EED-746D-4936-9C53-702D72DA84B8>