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

The Btrfs filesystem: An introduction

The Btrfs filesystem: An introduction

Posted Dec 12, 2013 4:39 UTC (Thu) by geuder (subscriber, #62854)
Parent article: The Btrfs filesystem: An introduction

Hmm, what about reliability? I think it's not too long that one could hear at least rumours about people losing data.

And wasn't there an issue with fsck?

Myself I have only 2 experiences:

- it was the default in the Meego systems I used. But for obvious reason that usage did not last long.

- when I once wanted a "portable" Ubuntu installed on a USB stick, I used btrfs because of the possibility to compress everything. Besides that it probably was only a 4GB stick, I thought the bigger the speed gap between CPU and "disk", the more beneficial compression should be for overall performance, because there are plenty of spare cycles. The overall result was catastrophic, because every bigger apt-get upgrade took really several hours. The reason was that apt seems to be really cautious about not ending up in an inconsistent state if aborted in the middle of an operation, so it does plenty of fsync (IIRC) calls. At least back then that was a known performance problem in btrfs. I shortly experimented with hooking eatmydata underneath apt, but for some reasons the project then faded out...
(I still wonder how Meego could live with that problem. Is it just the number of packages, which problably was only a fraction in a Meego tablet compared to a full Ubuntu desktop installation? Or is rpm less paranoid than apt about ending up with inconsistent results if something goes wrong?)


(Log in to post comments)

The Btrfs filesystem: An introduction

Posted Dec 13, 2013 10:47 UTC (Fri) by jezuch (subscriber, #52988) [Link]

> Hmm, what about reliability? I think it's not too long that one could hear at least rumours about people losing data.

I've been running btrfs on / for about 4 years, I think, and I can remember just one, non-data-eating incident. So no problems for me. But others[1] have very different experiences, so...

[1] http://changelog.complete.org/archives/9123-results-with-...

> The reason was that apt seems to be really cautious about not ending up in an inconsistent state if aborted in the middle of an operation, so it does plenty of fsync (IIRC) calls. At least back then that was a known performance problem in btrfs.

Yes, this was rather bad, but there was a workaround (tell APT to not be so damn paranoid). And this problem is long gone now.

The Btrfs filesystem: An introduction

Posted Dec 13, 2013 15:48 UTC (Fri) by jezuch (subscriber, #52988) [Link]

Oh, and BTW: my / contains only the things that I can lose and/or can be easily restored (like the operating system) so I'm not *that* crazy to give all my precious data to an experimental FS ;) (My precious data is on a RAID'ed XFS partition on at least two plain-old, trusted rotating-rust drives; the root is on an old-ish SSD from Intel.)

But I really like snapshotting. It revolutionized the way I do custom builds of Debian packages: create a snapshot, make a mess (installing build-dependencies etc.), build Chromium (lots and lots of thrashing, up to 20 GB of build artifacts), move away what's important, delete snapshot. And after all of this the main filesystem doesn't have a clue that anything happened. And I don't have to clean up anything at all :)

The Btrfs filesystem: An introduction

Posted Apr 1, 2014 16:12 UTC (Tue) by mcortese (guest, #52099) [Link]

(tell APT to not be so damn paranoid)

How? Especially when apt is called by the installer, not directly by the user?

The Btrfs filesystem: An introduction

Posted Apr 1, 2014 16:43 UTC (Tue) by hummassa (subscriber, #307) [Link]

load "eatmydata" and call the installer again :D


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