Hello everybody,
now that I have a live CD with btrfs support I decided to give btrfs on root
partition a try. I have good backups. ;) Here is what I have to tell so far:
* linking btrfsck to fsck.btrfs is a bad idea, it just crashes with signal 11.
My workaround is the following script:
#!/bin/bash
ARGS=$@
btrfsck ${ARGS##* }
* After a suspend cycle and some hours of work I got curious behaviour, e.g.
ld crashed while compiling the kernel. btrfsck found a lot of errors which I
did not save - stupid me. After that I did not suspend and had no further
corruption problems.
* btrfs seems to bring some latency problems. Sound skips from time to time
and the mouse pointer jumps on heavy disk io. I will try to find the reason
for this problem.
Beside this btrfs works perfectly... It's fast and stable. I will report
when
I have any news.
--
Regards,
Chris
On Feb 5 2008 21:36, Christian Hesse wrote:> >* btrfs seems to bring some latency problems. Sound skips from time to time >and the mouse pointer jumps on heavy disk io. I will try to find the reason >for this problem.It currently uses the BKL so that seems "normal" right now.
On Tuesday 05 February 2008, Christian Hesse wrote:> Hello everybody, > > now that I have a live CD with btrfs support I decided to give btrfs on > root partition a try. I have good backups. ;) Here is what I have to tell > so far: > > * linking btrfsck to fsck.btrfs is a bad idea, it just crashes with signal > 11. My workaround is the following script: > > #!/bin/bash > ARGS=$@ > btrfsck ${ARGS##* } > > * After a suspend cycle and some hours of work I got curious behaviour, > e.g. ld crashed while compiling the kernel. btrfsck found a lot of errors > which I did not save - stupid me. After that I did not suspend and had no > further corruption problems.Were these suspend problems before you applied Yan's patch for the free/thaw methods? -chris
On Tuesday 05 February 2008 21:36:27 Christian Hesse wrote:> now that I have a live CD with btrfs support I decided to give btrfs on > root partition a try. I have good backups. ;) Here is what I have to tell > so far:Here is one more data point. As an experiment I have used btrfs on / since 0.11 was released. Initially I believed that it wouldn't survive more than a few days, but I was wrong and now I must agree that it is quite stable. Great work! I have btrfs / on a usb stick, so the old filesystems are still safe on the hard drive if btrfs should eat my data. I have only found two issues: * No ENOSPC handling really sucks when your root file system is on a small usb stick. :-) * APT (Debian/Ubuntu package management) crashes when it tries to read its package lists. I have not had time to debug this yet, but a simple "aptitude update" is enough to reproduce the problem: root@garbage:~# aptitude update -- snip -- Fetched 3B in 0s (11B/s) Reading package lists... Error! E: Unable to determine the file size - fstat (75 Value too large for defined data type) E: Can't mmap an empty file W: You may want to run apt-get update to correct these problems E: Empty package cache E: Couldn't rebuild package cache root@garbage:~# Regards, P?r Andersson
2008/2/6, Christian Hesse <list@eworm.de>:> Hello everybody, > > now that I have a live CD with btrfs support I decided to give btrfs on root > partition a try. I have good backups. ;) Here is what I have to tell so far: > > * linking btrfsck to fsck.btrfs is a bad idea, it just crashes with signal 11. > My workaround is the following script: > > #!/bin/bash > ARGS=$@ > btrfsck ${ARGS##* } > > * After a suspend cycle and some hours of work I got curious behaviour, e.g. > ld crashed while compiling the kernel. btrfsck found a lot of errors which I > did not save - stupid me. After that I did not suspend and had no further > corruption problems.Are the errors found by btrfsck something like: --- ref mismatch on [xxx xxx] extent item xxx, found xxx backpointer mismatch on [xxx, xxx] If they are, I think the bug have been fixed in btrfs v0.12. Regards YZ