On Sat, Jan 09, 2016 at 09:59:29PM +0100, cheater00 . wrote: > OK. How do we track down that bug and get it fixed? I have no idea. I'm not a btrfs dev, I'm afraid. It's been around for a number of years. None of the devs has, I think, had the time to look at it. When Josef was still (publicly) active, he had it second on his list of bugs to look at for many months -- but it always got trumped by some new bug that could cause data loss. Hugo. > On Sat, Jan 9, 2016 at 9:26 PM, Hugo Mills <hugo@xxxxxxxxxxxxx> wrote: > > On Sat, Jan 09, 2016 at 09:00:47PM +0100, cheater00 . wrote: > >> Hello, > >> I can repeatedly trigger this bug by making the "data" portion fill > >> up. If you remember the partition is 6 TB but in btrfs filesystem df > >> Data is shown as only 2TB when in fact it should be nearly 6TB. So > >> this has nothing to do with kernel bugs. The filesystem on disk is > >> structured incorrectly. How do i fix this? How do I make "Data" > >> bigger? What is it exactly? > > > > This is *exactly* the behaviour of the known kernel bug. The bug is > > that the FS *should* be extending the data allocation when it gets > > near to full, and it's not. There is no way of manually allocating > > more (because the FS should be doing it automatically). There is no > > known way of persuading the FS to it when it isn't. > > > > The only good solution I know of is to reformat the FS and restore > > from backups. Even then, some people manage to repeatedly hit this > > with newly-created filesystems. > > > > Hugo. > > > >> Thanks > >> > >> P.S. Sorry about reposting twice, apparently Google's "Inbox" app > >> doesn't allow posting plain text at all and the mail got rejected from > >> the list. > >> > >> On Thu, 7 Jan 2016 23:22 Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > >> > > >> > On Thu, Jan 7, 2016 at 3:04 PM, cheater00 . <cheater00@xxxxxxxxx> wrote: > >> > > Yes, both times it was the same drive. I only have one usb drive now. > >> > > >> > That it's the same drive is suspicious. But I don't know what > >> > errno=-28 means or what could trigger it, if some USB weirdness could > >> > cause Btrfs to get confused somehow. I have one 7200rpm drive that > >> > wants 1.15A compared to all the others that have a 900mA spec, and > >> > while it behaves find 99% of the time like the others, rarely I would > >> > get the reset message and most of the time it was that drive (and less > >> > often one other). Now that doesn't happen anymore. > >> > > >> > > > >> > > I am not sure if chasing the kernel makes sense unless you think there is a > >> > > specific commit that would have foxed it. I only reported here in case > >> > > anyone here wanted to do some form of debugging before i reset the drive and > >> > > rescan the fs to make it writeable again. But since there seems to be no > >> > > interest i will go forward. > >> > > >> > I'd chase the hardware problem then first. It's just that the kernel > >> > switch is easier from my perspective. And it's just as unclear this is > >> > hardware related than just a bug. And since there are hundreds to > >> > thousands of Btrfs bugs being fixed per kernel release, I have no way > >> > to tell you whether it's fixed and maybe even a developer wouldn't > >> > either, you'd just have to try it. > >> > > >> > > > -- Hugo Mills | Hey, Virtual Memory! Now I can have a *really big* hugo@... carfax.org.uk | ramdisk! http://carfax.org.uk/ | PGP: E2AB1DE4 |
Attachment:
signature.asc
Description: Digital signature
