[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-bcache
Subject:    Re: Undoing an "Auto-Stop" when Cache device has recovered?
From:       "Nikolaus Rath" <nikolaus () rath ! org>
Date:       2021-03-25 6:16:17
Message-ID: 397bddb7-9750-4dd9-bf6e-2287d89778f1 () www ! fastmail ! com
[Download RAW message or body]


On Thu, 25 Mar 2021, at 05:29, Coly Li wrote:
> On 3/25/21 4:21 AM, Nikolaus Rath wrote:
> > Hello,
> > 
> > My (writeback enabled) bcache cache device had a temporary failure, but seems to \
> > have fully recovered (it may have been overheating or a loose cable). 
> > From the last kernel messages, it seems that bcache tried to flush the dirty \
> > data, but failed, and then stopped the cache device. 
> > After a reboot, the bcacheX device indeed no longer has an associated cache set..
> > 
> > I think in my case the cache device is in perfect shape again and still has all \
> > the data, so I would really like bcache to attach it again so that the dirty \
> > cache data is not lost. 
> > Is there a way to do that?
> > 
> > (Yes, I will still replace the device afterwards)
> > 
> > (I am pretty sure that just re-attaching the cacheset will make bcache forget \
> > that there was a previous association and will wipe the corresponding metadata). 
> 
> Hi Nikolaus,
> 
> Do you have the kernel log? It depends on whether the cache set is clean
> or not. For a clear cache set, the cache set is detached, and next
> reattach will invalidate all existing cached data. If the cache set is
> dirty and all existing data is wiped, that will be fishy....

Hi Cody,

I'm not sure I understand. I believe there is dirty data on the cacheset (it was \
effectively disconnected in the middle of operations). Also, if it wasn't dirty then \
there would be no need to re-attach it (all the important data would be on the \
backing device).

On the other hand, after a reboot the cache set shows up in /sys/fs/bcache - just not \
associated with any backing device. So I guess from that point of view it is clean?

The kernel logs are on the affected bcache, and I have avoided doing anything with it \
(including mounting). I took a few pictures of the last visible messages on the \
console before re-booting though. For example, here is when the problem starts

First ATA errors: https://drive.google.com/file/d/1_vr-JBWZjajzbWyXUSmtn4faNH6072ut/view?usp=sharing
 First bcache errors: \
https://drive.google.com/file/d/1XLCWDi6G2lP1JiVitZTtIqzB4QqxXv2-/view?usp=sharing

Does that help?

Best,
-Nikolaus

--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

              »Time flies like an arrow, fruit flies like a Banana. «


[prev in list] [next in list] [prev in thread] [next in thread]