Hi, On Thu, Oct 27, 2011 at 10:24:05AM +0200, Gaudenz Steinlin wrote: > On Wed, 26 Oct 2011 23:21:33 +0530, Christian PERRIER <bubulle@debian.org> wrote: > > > > > > > > Maarten <mvrossen@gmail.com> writes: > > > > > > > Package: btrfs > > > > Severity: critical > > > > Justification: causes serious data loss > > > > > > > > BTRFS shouldn't be offert as a option filesystem in the debian installer. > > > > It is unsafe to use. Quallity is poor. No recovery possible on filesystem errors. (The btrfs driver will even crash on a filesystem error) > > > > The provided tool btrfsck doesn't actually do anything. > > > > There doesn't seem to be any progres on a working btrfsck. > > > > > > > > Atleased users should be warned to not use it, unless they don't > > > > care about dataloss > > Do you have any real world cases to support these claims using a recent > kernel version (at least the version currently in testing). > > > > > > > There is no btrfs package in Debian, thus, this report did not reach any > > > developers. Furthermore, since it is the installer that is allegedly at > > > fault, it should be filed against the debian-installer package. > > > > > > I went ahead and reassigned it there. > > > > > > Well, if btrfs is in such a bad shape, then partman-btrfs should be > > made optional so that only those people who really want it will have > > it as an option. > > > > I don't think that dropping the package entirely is the best > > option. But making it less "visible" in D-I is probably good if I > > believe in the above claims (I have no idea about this to be true or > > not). > > With my own experience with BTRFS I can not support the above claims. In > several tests and while running my laptop with BTRFS I never saw any > data loss. While it's true that there is no external filesystem checker > (aka "btrfsck") as this is a journaling filesystem such a tool is much > less needed than for a non journaling filesystem. Also a btrfsck tool > is in the works, but it's unclear when it will be released. > > The main reason why I would not recommend btrfs on Debian for / is it's very > poor fsync performance which makes apt runs a pain in the ass if you > don't use "eatmydata" which disables fsync. But that's a performance and > not a corectness issue. > > BTRFS might be unreliable with the current stable kernel. I did not test > this. So if someone really belives that BTRFS should be less visible, > just do that for the stable installer (if thats possible wrt stable > update policies). > I've been using btrfs since mid 2014, and it has been problem-free since sometime in 2017 with linux-4.4.x. Fsync performance seems to have improved (still not great), but IO latency under load for an aged filesystem is still sometimes awful. Tracking the latest stable upstream kernel (incl. testing/sid) rather than LTS kernel is still risky and presents increased exposure to new bugs, but this is documented on our wiki. Imho this bug is no longer relevant and should be closed. Regards, Nicholas
Attachment:
signature.asc
Description: PGP signature