Re: [RFC] Add sysctl option to drop disk flushes in bcache? (was: Bcache in writes direct with fsync)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 31, 2022 at 04:04:12PM -0700, Eric Wheeler wrote:
> 
>   * Write-through: write is done synchronously both to the cache and to 
>     the backing store.
> 
>   * Write-back (also called write-behind): initially, writing is done only 
>     to the cache. The write to the backing store is postponed until the 
>     modified content is about to be replaced by another cache block.
>   [ https://en.wikipedia.org/wiki/Cache_(computing)#Writing_policies ]
> 
> 
> So the kernel's notion of "write through" meaning "Drop FLUSH/FUA" sounds 
> like the industry meaning of "write-back" as defined above; conversely, 
> the kernel's notion of "write back" sounds like the industry definition of 
> "write-through"
> 
> Is there a well-meaning rationale for the kernel's concept of "write 
> through" to be different than what end users have been conditioned to 
> understand?

I think we all agree what "write through" vs "write back" mean. I'm just not
sure what's the source of the disconnect with the kernel's behavior.

  A "write through" device persists data before completing a write operation.

  Flush/FUA says to write data to persistence before completing the operation.

You don't need both. Flush/FUA should be a no-op to a "write through" device
because the data is synchronously committed to the backing store automatically.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM Kernel]     [Linux Filesystem Development]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux