Re: Oops when mounting btrfs partition

2013-02-11 Thread Arnd Bergmann
On Friday 08 February 2013, David Sterba wrote: > On Mon, Feb 04, 2013 at 09:55:50PM +, Arnd Bergmann wrote: > > On Saturday 02 February 2013, Chris Mason wrote: > > > > I've done a full backup of all data now, without any further Ooops > > messages, but > > I did get these: > > > > [66155.4

Re: Oops when mounting btrfs partition

2013-02-08 Thread David Sterba
On Mon, Feb 04, 2013 at 09:55:50PM +, Arnd Bergmann wrote: > On Saturday 02 February 2013, Chris Mason wrote: > > I've done a full backup of all data now, without any further Ooops messages, > but > I did get these: > > [66155.429029] btrfs no csum found for inode 1212139 start 23707648 The

Re: Oops when mounting btrfs partition

2013-02-04 Thread Arnd Bergmann
On Saturday 02 February 2013, Chris Mason wrote: > > Feb 1 22:57:37 localhost kernel: [ 8561.599482] Kernel BUG at > > a01fdcf7 [verbose debug info unavailable] > > > Jan 14 19:18:42 localhost kernel: [1060055.746373] btrfs csum failed ino > > 15619835 off 454656 csum 2755731641 privat

Re: Oops when mounting btrfs partition

2013-02-02 Thread Arnd Bergmann
On Saturday 02 February 2013 10:20:35 Chris Mason wrote: > Hi Arnd, > > First things first, nospace_cache is a safe thing to use. It is slow > because it's finding free extents, but it's just a cache and always safe > to discard. With your other errors, I'd just mount it readonly > and then you

Re: Oops when mounting btrfs partition

2013-02-02 Thread Chris Mason
Hi Arnd, First things first, nospace_cache is a safe thing to use. It is slow because it's finding free extents, but it's just a cache and always safe to discard. With your other errors, I'd just mount it readonly and then you won't waste time on atime updates. I'll take a look at the BUG you g