A short history of btrfs

Posted Jul 30, 2009 8:00 UTC (Thu) by alkby (guest, #59504)
Parent article: A short history of btrfs

I don't get one thing about this COW thing. Why it's so good ? That's convenient for snapshots, but
if I don't use snapshots and have huge files and often rewrite their pieces then they'll become
highly fragmented, right ?

Imagine a database data file that is organized as a btree itself. Some database rows will be
updated, and most DBMS do that in-place. So our modern COW filesystem will gradually
fragment that data file. And when DBMS will do, say a range scan in btree it will expect mostly
linear (and fast) disk IO, while in fact it will get random (and dead slow) IO. Maybe I've missed
something important here?

A short history of btrfs

Posted Aug 4, 2009 0:51 UTC (Tue) by wmf (guest, #33791) [Link]

COW is also crash-safe without the overhead of journaling.

A short history of btrfs

Posted Aug 4, 2009 15:41 UTC (Tue) by topher (guest, #2223) [Link]

Some database rows will be updated, and most DBMS do that in-place.

This is actually incorrect. There are almost no databases that actually do that anymore. All modern (decent) databases will create a new row when performing an update, and then mark the old row as deleted internally. This is significantly safer, performs better, and allows you to support other important transactional features.