Re: 6TB partition, Data only 2TB - aka When you haven't hit the "usual" problem

[Hugo Mills <hugo@carfax.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 3493 bytes --]

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@carfax.org.uk> 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@colorremedies.com> wrote:
> >> >
> >> > On Thu, Jan 7, 2016 at 3:04 PM, cheater00 . <cheater00@gmail.com> 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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]