And don't bump old theads with outdated information.
]]>ln -s /usr/bin/btrfsck /sbin/fsck.btrfs.
Don't do this, for the reasons stated by other replies. btrfs wiki recommends "ln -s /usr/bin/true /sbin/fsck.btrfs" if you want to silence such errors.
]]>btrfs ensures consistency by virtue of being a CoW filesystem. If you have the space available to write new data, you write the new data, checksum it, and then do an atomic pointer swap in the underlying metadata to point to the newly written data. You are "guaranteed" consistency before and after the operation. I say "guaranteed", because ZFS followed this same mantra and found out that hardware defects can still cause inconsistencies in the data sets. For these rare cases, btrfs implemented a fsck tool. ZFS never did.
This is different from how Ext filesystems work -- in the case of corruption, you may not have consistent data state. Replaying the journal via fsck attempts to fix this. It's necessary to read the superblock and check for an inconsistent state on every mount. This is what fsck does for Ext filesystems.
This is an abolsute jewel of information here. Thanks falconindy!
]]>This is different from how Ext filesystems work -- in the case of corruption, you may not have consistent data state. Replaying the journal via fsck attempts to fix this. It's necessary to read the superblock and check for an inconsistent state on every mount. This is what fsck does for Ext filesystems.
]]>btrfs does not want fsck routinely run at bootup like extN filesystems want.
why do you say that ? it is not always a good idea to make fsck at the startup?
]]>http://beefdrapes.partedmagic.com/sourc … fsck.btrfs
and seems to work ok.
Edit: It doesn't work so well when your root partition is btrfs. Obviously the partition is un-mounted and /sbin/btrfsck is not accessible.
]]>jcci wrote:ln -s /usr/bin/btrfsck /sbin/fsck.btrfs
This is a simple solution and should do no harm. Worked for me.
Might silence the error message on boot and won't do any harm but probably will not really work either. Calling semantics of btrfsck and fsck.* differ.
I discovered this when I thought came upon the idea of making that links as well. You may not get an error when you make the initramd, but you end up with an error message on every boot, indicating that it is trying to use a given flag. Upon inspecting the btrfsck man page, I discovered that it does not accpet any flags.
]]>ln -s /usr/bin/btrfsck /sbin/fsck.btrfs
This is a simple solution and should do no harm. Worked for me.
Might silence the error message on boot and won't do any harm but probably will not really work either. Calling semantics of btrfsck and fsck.* differ.
]]>