[zfs-discuss] Should I disable disk write cache ?

Homer Li 01jay.ly at gmail.com
Thu Sep 3 23:31:13 EDT 2015


Thank you all

Etienne, in my question ,the disk supports DPO and FUA, but there are some
SATA disk not support them.
like this:
"[sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
"

If no DPO ,no FUA, and enabled write cache , Could fsync() guarantee
consistency
and durability ?

https://en.wikipedia.org/wiki/Disk_buffer
it said "in contrast to corresponding commands without FUA, write data
directly to the media, regardless of whether write caching in the device is
enabled or not. FUA write command will not return until data is written to
media, thus data written by a completed "

I guess VDEV_WRITE_FLUSH_FUA BIO depends return code of FUA. but I 'm not
sure. I guess because the name contains "FUA".
Does it mean if you want enable write cache , your hard disk must support
FUA ?

On Thu, Sep 3, 2015 at 5:35 PM, Etienne Dechamps via zfs-discuss <
zfs-discuss at list.zfsonlinux.org> wrote:

> On 2 September 2015 at 11:17, Gordan Bobic via zfs-discuss <
> zfs-discuss at list.zfsonlinux.org> wrote:
>
>> One thing to be aware of however - I have looked at zfs-fuse code in some
>> detail, and that includes code that explicitly issues disk flush commands
>> to the underlying block device. Unfortunately, it doesn't distinguish
>> between partitions and raw disks, so on some kernels it results in a flood
>> of warnings from the kernel about issuing an ioctl to a partition, but this
>> may be harmless.
>>
>> The important thing to note, however, is that the same code doesn't exist
>> in ZoL, so if that is in fact issuing barriers, it is doing it some other
>> way from some other place in the code.
>>
>
> In ZoL the DKIOCFLUSHWRITECACHE ioctl zio (which is issued from
> zio_flush(), itself issued from places such as zil_flush_vdevs()) ends up
> calling vdev_disk_io_flush(), which results in a
> VDEV_WRITE_FLUSH_FUA BIO being issued to the Linux kernel disk I/O
> subsystem. This is a write barrier operation, which (typically) makes the
> Linux kernel trigger a full device queue flush followed by the appropriate
> write cache flush command to the device. As far as I know there is nothing
> wrong with these code paths and they provide the necessary guarantees as
> long as the Linux drivers and the underlying hardware do what they're told.
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at list.zfsonlinux.org
> http://list.zfsonlinux.org/cgi-bin/mailman/listinfo/zfs-discuss
>
>


-- 
Best Regards
Homer Li
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.zfsonlinux.org/pipermail/zfs-discuss/attachments/20150904/6beed400/attachment-0001.html>


More information about the zfs-discuss mailing list