User: Password:
|
|
Subscribe / Log in / New account

A short history of btrfs

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?


(Log in to post comments)

A short history of btrfs

Posted Aug 4, 2009 0:51 UTC (Tue) by wmf (subscriber, #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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds