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:
> >
> >
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.429029] btrfs
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
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
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
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 private
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
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
As mentioned on Google+, I have a partition that I can no longer mount
normally, containing a lot of my personal data and all backups from
my laptop.
I found now that I am still able to mount it using the 'nospace_cache'
option, but it takes a couple of minutes and I get "INFO: task
As mentioned on Google+, I have a partition that I can no longer mount
normally, containing a lot of my personal data and all backups from
my laptop.
I found now that I am still able to mount it using the 'nospace_cache'
option, but it takes a couple of minutes and I get INFO: task
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
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 won't
12 matches
Mail list logo
