Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Marc Joliet <marcec@gmx.de>
To: linux-btrfs@vger.kernel.org
Subject: Re: Poll: time to switch skinny-metadata on by default?
Date: Mon, 27 Oct 2014 02:30:23 +0100	[thread overview]
Message-ID: <20141027023023.0732985a@marcec.fritz.box> (raw)
In-Reply-To: <20141025215808.1ad14aa0@marcec>

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

Am Sat, 25 Oct 2014 21:58:08 +0200
schrieb Marc Joliet <marcec@gmx.de>:

> Am Sat, 25 Oct 2014 14:24:58 +0200
> schrieb Marc Joliet <marcec@gmx.de>:
> 
> > I can still access files on MARCEC_BACKUP just fine, and the snapshots are
> > still there ("btrfs subvolume list" succeeds).
> 
> Just an update: that was true for a while, but at one point listing directories
> and accessing the file system in general stopped working (all processes that
> touched the FS hung/zombified). This necessitated a hard reboot, since "reboot"
> and "halt" (so... "shutdown", really) didn't do anything other than spit out the
> usual "the system is rebooting" message.
> 
> Interestingly enough, the file system was (apparently) fine after that (just as
> Petr Janecek wrote), other than an invalid space cache file:
> 
>   [   65.477006] BTRFS info (device sdg2): The free space cache file
>   (2466854731776) is invalid. skip it
> 
> That is, running my backup routine worked just as before, and I can access
> files on the FS just fine.
> 
> Oh, and apparently the rebalance continued successfully?!
> 
>   [  342.540865] BTRFS info (device sdg2): continuing balance
>   [  342.599991] BTRFS info (device sdg2): relocating block group 2502355320832
>   flags 34 [  342.821608] BTRFS info (device sdg2): found 4 extents
>   [  343.056915] BTRFS info (device sdg2): relocating block group 2501818449920
>   flags 36 [  437.932405] BTRFS info (device sdg2): found 25086 extents
>   [  438.727197] BTRFS info (device sdg2): relocating block group 2501281579008
>   flags 36 [  557.319354] BTRFS info (device sdg2): found 83875 extents
> 
>   # btrfs balance status /media/MARCEC_BACKUP
>   No balance found on '/media/MARCEC_BACKUP'
> 
> No SEGFAULT anywhere. All I can say right now is "huh". Although I'll try
> starting a "balance -m" again tomorrow, because the continued balance only
> took about 3-4 minutes (maybe it .

Maybe it exploded, I don't know (sorry, clearly I didn't delete the entirety of
that incomplete train of thought).

Anyway, I did run a full "balance -m" again, and this time it finished
successfully.  Make of that what you will, but it appears that the bug is
non-deterministic (makes me wonder if Petr Janecek or anybody else who hit the
bug ever got a balance to finish).

HTH
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2014-10-27  1:30 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-16 11:33 Poll: time to switch skinny-metadata on by default? David Sterba
2014-10-20 16:34 ` David Sterba
2014-10-21  9:29   ` Duncan
2014-10-21 11:02     ` Austin S Hemmelgarn
2014-10-21 12:35       ` Konstantinos Skarlatos
2014-10-21 16:40     ` Rich Freeman
2014-10-22  2:08       ` Duncan
2014-10-22 12:49         ` Dave
2014-10-23  2:41           ` Duncan
2014-10-23 13:37             ` David Sterba
2014-10-23 14:47         ` Tobias Geerinckx-Rice
2014-10-24  1:33           ` Duncan
2014-10-25 12:24   ` Marc Joliet
2014-10-25 19:58     ` Marc Joliet
2014-10-27  1:30       ` Marc Joliet [this message]
2014-10-25 20:33     ` Chris Murphy
2014-10-25 20:35       ` Chris Murphy
2014-10-27  1:24         ` Marc Joliet
2014-10-27  7:50           ` Duncan
2014-10-27  4:39   ` Zygo Blaxell
2014-10-27  7:16     ` Duncan
  -- strict thread matches above, loose matches on Subject: below --
2014-10-17 12:30 Petr Janecek
2014-10-17 18:25 ` Josef Bacik
2014-10-18 11:21   ` Petr Janecek
2014-10-18 14:04     ` Josef Bacik
2014-10-18 15:52       ` Wang Shilong
2014-10-18 15:53         ` Josef Bacik
2014-10-18 16:01           ` Wang Shilong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141027023023.0732985a@marcec.fritz.box \
    --to=marcec@gmx.de \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox