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. Probably this is 'the' bug we talk about: https://bugzilla.kernel.org/show_bug.cgi?id=74101 Size of the fs is much smaller, but also problem occurs when fill-level is <50% btrfs fs resize did nothing you mention, but AFAIK you should see something in dmesg when you do that. And what is the output of gdisk -l /dev/sdd , just to check? Have you had the fs already filled up to e.g. 95% before or has is always been not more than 2TiB? Why are the single (empty )profiles for metadata and system still there? They should have been removed already by the various balancing operations that are advised in the btrfs-wiki. What is the output of btrfs check /dev/sdd ? The usb resets mentioned might have introduced some errors to the fs (that is what I have experienced at least, but it depends on timing etc) What you could try is to create an image+'copy' of the fs with btrfs-image just after you get ENOSPC abd then do various tests with that (make sure unmount or even better unplug the physical hdd!). Like mounting and then try to add a file, convert all metadata + system from dup to single and then try to add a file. It all doesn't give real space, but it might give hints to what could be wrong. If you somehow manage to reduce the fs by lets say 100G and also the partition, you could install or copy a newer linux+kernel to partition(s) in that 100G space and boot from there. > 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
