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: 4615 bytes --]

On Sat, Jan 09, 2016 at 10:07:50PM +0100, cheater00 . wrote:
> Would like to point out that this can cause data loss. If I'm writing
> to disk and the disk becomes unexpectedly read only - that data will
> be lost, because who in their right mind makes their code expect this
> and builds a contingency (e.g. caching, backpressure, etc)...
> 
> There's no loss of data on the disk because the data doesn't make it
> to disk in the first place. But it's exactly the same as if the data
> had been written to disk, and then lost.

   That's only the same kind of data loss that you'd encounter if the
power went out unexpectedly at the same point. The application isn't
told that data has been written to disk when it hasn't. It's far from
a good situation, but it's not a failure of data durability.

   Hugo.

> On Sat, Jan 9, 2016 at 10:04 PM, Hugo Mills <hugo@carfax.org.uk> wrote:
> > 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             | make bzImage, not war
hugo@... carfax.org.uk |
http://carfax.org.uk/  |
PGP: E2AB1DE4          |                                       Markus Reichelt

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]