On Mon, Apr 20, 2015 at 10:13:47AM +0200, Gian-Carlo Pascutto wrote: > On 20-04-15 06:27, Zygo Blaxell wrote: > > >> I'm curious as to whether +C has any effect on BTRFS's durability, too. > > > > I would expect it to be strictly equal to or worse than the CoW > > durability. > > In addition to the stuff pointed out, I've wondered about this: > PostgreSQL full_page_writes copies 8k pages in order to prevent > corruption from partial writes. But btrfs has 16k pages by default, so a > corrupted FS page would corrupt more data than PostgreSQL protects.
There are multiple page sizes in a btrfs. *Metadata* pages are 16K by default. Metadata is always CoW in btrfs. *Data* pages are 4K by default. AIUI the btrfs code currently heavily relies on data page and host CPU page sizes being identical. I don't know what happens on architectures with 8K page sizes--it's been years since I booted an Alpha machine. > Maybe it's not an issue if the underlying HW has 512b/4k sectors, or > maybe I'm misunderstanding what the respective features assume, but > unless informed to the contrary I wouldn't be entirely comfortable with > this. Usually writes are issued in multiples of 4K pages at a time from the kernel, so the underlying sector size only comes into play when something interrupts a disk between individual sector writes within a page. full_page_writes should handle no-CoW on btrfs (or any other filesystem) just fine. It's the *other* btrfs bugs you have to worry about. ;) > (With CoW enabled, you don't have partial writes, so the point is moot) > > -- > GCP > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
signature.asc
Description: Digital signature
