OK. How do we track down that bug and get it fixed? 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 | -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
