On Mon, Jul 08, 2013 at 02:29:05PM +0200, Takashi Iwai wrote:
IIRC, this was the heavily patched 3.1.x based kernel from opensuse 12.1, right? Lots of backports were taken from sles kernel, but as there were newer opensuse releases available, 12.1 did not get many updates and some bugs were left. Using a recent kernel is recommended.
This was with a custom built kernel, 3.9-rc-something, IIRC. So this must have been an upstream bug.
Depends which rc it was, I've checked the -rc patch series incrementally and there were several fixes in each, some of them could cause the problems.
A sudden -ENOSPC is unavoidable as a nature of COW, especially when snapshots are taken automatically. But, the behavior like this (refusing any actions including mount) is a literally disaster, which must not happen. If mount may be refused, at least a proper fsck must be provided instead of a random tool.
Yeah the enospc situation is far from perfect, but has improved over time.
I hope it sincerely :)
Though, as someone already mentioned in another same thread on FACTORY ML, a sane automatic recovery would be really required, no matter how stable the filesystem is. A breakage may happen not only by a software bug but also by faulty hardware. The lack of fsck is one of the biggest hindrances for recommending btrfs for daily use, even if it's just a matter of mental ease.
There are some measures against bugs caused by faulty hardware, notably the checksums (disk bitrot or memory errors), block number is recorded and verified upon read (ghost writes), tree blocks reads verify the transaction id (overwritten blocks or stale). Automatic recovery should take place when it's either clear what type of error happend and that the recovery steps will not break it even more. Currently the autorecovery options offer to go back in time and try to access start from previously known to be good version (-o recovery). If the filesystem is damaged despite all the integrity checks passing, then it's in an unknown inconsistent state and I don't see many sane options to do safe automatic repair. fsck (the part that checks) verifies links between structures with regard to reference counts and owners (ie subvolumes), or the allocation structures' integrity. The basic verification has been present for a long time, what's being added over time are bugfixes that are based on user reports, or major features that are eg able to rebuild the tree structures from the ground up after a severe corruptions. That btrfs has no fsck is part of the folklore, and unlikely to disappear. I personally never had to use it on a filesystem where I keep non-testing data. david -- To unsubscribe, e-mail: email@example.com To contact the owner, e-mail: firstname.lastname@example.org