Re: bcache writeback infinite loop?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On 10/30/2019 3:18 PM, Kai Krakow wrote:
> >> I did a scrub with bcache running and 19 errors were found and corrected
> >> using duplicate metadata. That seems encouraging.
> > What kind of scrub? Did it affect bcache caching or backing device?
>
> btrfs scrub. Not sure what, if anything, was actually effected.

So this should do nothing about any loops you're facing in bcache.
Bcache doesn't care about which FS it serves, it's just a bunch of
data. No matter what you fix or reorganize in the background: It's
still a bunch of data to bcache.


> >> Unfortunately, I can't
> >> seem to shut down bcache in order to test as you suggest. I can stop
> >> bcache0 but I am unable to stop the cache device. I do the usual:
> >>
> >> echo 1 > /sys/fs/bcache/dc2877bc-d1b3-43fa-9f15-cad018e73bf6/stop
> > I was seeing a similar issue. I'm not sure "stop" always works as
> > expected. You should try "detach" instead. When it finished writeback
> > eventually, it would detach cache from backing, and upon next mount
> > they won't be attached to each other any longer and you should be able
> > to unmount.
> >
> > If you cannot get rid of dirty data, you could also unregister bcache,
> > then wipe the cache device, and then re-register and force-run the
> > bcache backing device. Tho, discarding write-back data will eventually
> > damage your FS. You should try switching to write-around first and see
> > if you can convince bcache to write back data that way (maybe through
> > a clean reboot after switching to write-around).
>
> Duh, yes, unregistering the backing device did what I needed.

Sometimes it helps to just talk about it again. ;-)


> I'm now
> running a new scrub without the cache device. Interestingly, the initial
> scrub speed with bcache ran at 900MB/s and without bcache it's 1400MB/s.

Yes, I can confirm that bcache throughput performance has degraded a
lot over time. Latency performance is still very good. But I was never
sure if this comes from general kernel changes, btrfs, or bcache
itself.


> Thanks for the un-register tip!

You're welcome.

- Kai



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM Kernel]     [Linux Filesystem Development]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux