On Sun, Sep 11, 2016 at 8:00 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Chris Murphy posted on Sun, 11 Sep 2016 14:33:18 -0600 as excerpted:
>
>> Something else that's screwy in that bug that I just realized, why is it
>> not defaulting to mixed-block groups on a 1
y should it be in multiples? I think what you're describing is part
of the bug above that just needs to be fixed. Btrfs itself internally
uses bytes, so multiples of 64MiB is OK but I wouldn't use the word
"should" with it.
--
Chris Murphy
--
To unsubscribe from this list: send the line &
know why that would be, as metadata itself
isn't compressed (the inline data saved in metadata nodes can be
compressed). But there you go, if things start going wonky compression
might make it more difficult. But that's speculative. And I also don't
know if there's any difference between lzo and zlib in
e rest of the wiki for
details that are often repeated on the list but shouldn't need to be
repeated on the list. And then the list for conversations/evaluations.
It is really a lot easier to make the wiki too verbose, making good
info harder to find. Wherever possible just take a stand, have an
opin
ittle annoyed the developer to user communication is
lacking significantly enough that this miscommunication can happen, on
the other hand I realize they're up to their eyeballs doing things
they do best which is fixing bugs and adding features. I don't know
that anyone has a perfect idea of what i
On Fri, Sep 9, 2016 at 12:58 PM, Chris Murphy <li...@colorremedies.com> wrote:
>
> It should work better than it does because it works well for LVM and
> mdadm arrays.
>
> I think what's going on is the DE's mounter (udisksd) tries to mount
> each Btrfs device node, even
just these two devices. None of the others
is totally full either.
Sounds like with enospc devs want to see a couple things beyond what I
asked for:
enospc_debug
grep -IR . /sys/fs/btrfs/UUID/allocation/
That's kinda hard to do right now if it's not mounting though...
--
Chris Murphy
--
To u
less blocked
*shrug* I'd use XFS for the stick file system for /var.
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Sep 8, 2016 at 5:48 AM, Austin S. Hemmelgarn
<ahferro...@gmail.com> wrote:
> On 2016-09-07 15:34, Chris Murphy wrote:
> I like the idea of matching WWN as part of the check, with a couple of
> caveats:
> 1. We need to keep in mind that in some environments, t
default mounts for
the above, don't include the compression option. You could also try -o
ro,recovery and see where that gets you.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
r
so things are mounted and umounted correctly as most DE's now expect
to just automount everything. I still get weird behaviors on GNOME
with udisks2 and multiple device Btrfs volumes with current upstream
GNOME stuff.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsub
ogfiles from the check.
>
>
> What do they mean?
https://bugzilla.kernel.org/show_bug.cgi?id=155791
http://www.spinics.net/lists/linux-btrfs/msg58142.html
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
s: 683851776
> btree space waste bytes: 2859469730
> file data blocks allocated: 16171232772096
> referenced 13512171663360
>
> What does that tell us?
>
Qu might have an idea, I don't. Looks like quotas are enabled, as well
as compression; but I have no idea if they're related
ng. If there were any files corrupt, they now
have csums based on that corruption, so they will read as OK by Btrfs.
That's the problem with init-csum-tree. So now you need a different
way to confirm/deny if they files are really good or not.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
f data:
> the backup and the current degraded filesystem.
> If data differs, which one do I take? Is it safe to use the more recent one
> from the degraded filesystem?
If data differs you have to figure out a way to inspect the file to
determine which one is correct. Databases have their
On Fri, Sep 2, 2016 at 9:47 PM, Ronan Arraes Jardim Chagas
<roni...@gmail.com> wrote:
> Hi Chris,
>
> Em Sex, 2016-09-02 às 21:41 -0600, Chris Murphy escreveu:
>> I suggest removing the hardware, and the proprietary driver, and
>> retest the system with the exist
On Fri, Sep 2, 2016 at 8:47 PM, Ronan Arraes Jardim Chagas
<roni...@gmail.com> wrote:
> Hi guys!
>
> Em Sex, 2016-09-02 às 16:39 -0600, Chris Murphy escreveu:
>> Worth a shot, considering the opensuse/SLE 4.4 kernel has a shittonne
>> of backports. It seems unli
On Fri, Sep 2, 2016 at 4:13 PM, Ronan Arraes Jardim Chagas
<roni...@gmail.com> wrote:
> Hi!
>
> Em Sex, 2016-09-02 às 15:34 -0600, Chris Murphy escreveu:
>> Except for your software build case, I have about the same workload
>> you have with two machines, one SSD one H
easily finding that particular one,
but I did find something a bit more recent:
http://download.opensuse.org/repositories/Kernel:/openSUSE-42.2/standard/x86_64/
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kerne
ir 4.4 kernel magically stable. If
they're using out of tree quota code, fine, remove the warnings. But
then, what is this code? How does it interact with upstream kernels?
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a m
; >> -Original Message-
>> >> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
>> >> ow...@vger.kernel.org] On Behalf Of Chris Murphy
>> >> Sent: Thursday, 1 September 2016 7:59 AM
>> >> To: Btrfs BTRFS <linux-btrfs@vger.kern
OK I filed a bug:
progs 4.7.x, numerous incorrect backrefs are not fixed with --repair
https://bugzilla.kernel.org/show_bug.cgi?id=155791
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
usting a quota limit doesn't
cause a very explicit quota related message, rather than a generic
enospc?
[1] https://lists.opensuse.org/opensuse-factory/2016-09/msg00033.html
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of
rent state, and then try a --repair and if it breaks the file
system I'm probably going to go ballistic...
---
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
rting was behavior that no one on this list has
ever previously reported. And upstream does not have quotas enabled by
default so there is no reason why any regular testers here would have
come across this.
So now we come full circle and I have to call this a misfeature that's
trying to mak
On Thu, Sep 1, 2016 at 11:59 AM, Chris Murphy <li...@colorremedies.com> wrote:
> OK so I have a 2nd volume, which is only ever used to 'btrfs receive'
> from the 1st volume. The 2nd volume is never persistently mounted. But
> it too has bunches of these incorrect backref messages
On Thu, Sep 1, 2016 at 12:51 AM, Paul Jones <p...@pauljones.id.au> wrote:
>> -Original Message-
>> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
>> ow...@vger.kernel.org] On Behalf Of Chris Murphy
>> Sent: Thursday, 1 September 2016 7:59 AM
&
On Wed, Aug 31, 2016 at 5:03 PM, Jeff Mahoney <je...@suse.com> wrote:
> On 8/31/16 6:58 PM, Chris Murphy wrote:
> Does Ronan's call trace showing
>> /fs/btrfs/qgroup.c:2667
>>> btrfs_qgroup_free_meta implicate qgroups as a possible source of his
>>> p
On Wed, Aug 31, 2016 at 4:47 PM, Jeff Mahoney <je...@suse.com> wrote:
> On 8/31/16 5:48 PM, Chris Murphy wrote:
>> OK it looks like with -w flag I can get a reliable indication of
>> whether quota is enabled or not:
>>
>> [root@f24s ~]# btrfs quota enable /mn
This is still happening with btrfs-progs 4.7.1 and there is zero
information in the long result what to do about the problem, and
whether it's sane to try have --repair fix it, let alone what the
original cause of the problem was.
--
Chris Murphy
--
To unsubscribe from this list: send the line
someone can point out an easier way to determine whether
quotas are enabled?
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
quota is enabled on a Btrfs file system. There's enable, disable,
and rescan. If it's enabled or disabled, I get the same message if I
rescan. If I mount the file system with quota previously enabled,
there is no mount time notification that quota is enabled.
I sincerely hope opensuse isn't enabl
On Tue, Aug 30, 2016 at 3:23 PM, Gareth Pye <gar...@cerberos.id.au> wrote:
> On Wed, Aug 31, 2016 at 4:28 AM, Chris Murphy <li...@colorremedies.com> wrote:
>> But I'd try a newer kernel before you
>> give up on it.
>
>
> Any recommendations on liveCDs th
On Tue, Aug 30, 2016 at 12:04 PM, Chris Murphy <li...@colorremedies.com> wrote:
> One of us would have to go look in source to see what causes "[
> 163.612313] BTRFS: failed to read the system array on sdd" to appear
https://git.kernel.org/cgit/linux/kernel/git/stable/li
erblocks?
What do you get for
btrfs rescue super-recover -v /dev/sdX ?
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
if things work again. It's a reasonably good idea
though to just delete any associated file, because that will cause its
metadata to go away also, and the source of this problem. But often a
leaf or node will contain references to more than just one file.
--
Chris Murphy
--
To unsubscribe from
On Tue, Aug 30, 2016 at 4:22 AM, ojab // <o...@ojab.ru> wrote:
> On Mon, Aug 29, 2016 at 9:05 PM, Chris Murphy <li...@colorremedies.com> wrote:
>> On Mon, Aug 29, 2016 at 10:04 AM, ojab // <o...@ojab.ru> wrote:
>> What do you get for 'btrfs fi us '
>
>
an disable snapper snapshots entirely and
the problem doesn't happen; or if you can increase the frequency of
snapper snapshots and the problem happens more often, that might help
narrow it down to a point where it's more easily reproduced. If it's
not related, that's still useful to know.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
lance?
You can see what the state of block groups are with btrfs-debugfs
which is in kdave btrfs-progs git. Chances are you need a larger
value, -dusage=15 -musage=15 to free up space on devid 1 and 2. Then
maybe devid 3 can be removed.
--
Chris Murphy
--
To unsubscribe from this list: send the
en I think this feature should be
> mentioned in the send/receive manpages.
I don't see evidence of them in the btrfs send file, so I don't think
csums are in the stream.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message
's
some bug somewhere: somehow it became inconsistent, and can't be fixed
at mount time or even with btrfs check.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
out
The SCTERC value must be less than the timeout. This really must be
the first thing you do, even before starting your backup, because
otherwise a misconfiguration here has a very good chance of preventing
the success of getting a backup. Note these are not persistent
settings.
--
Chris
rectories for multiple write streams has better
concurrency handling and less contention.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 26, 2016 at 1:18 PM, Gert Menke <g...@menke.ac> wrote:
> Hi Chris,
>
> first off, thank you for the detailled explanations!
>
> On 2016-08-26 01:04, Chris Murphy wrote:
>>
>> No, it's not a file, directory or subvolume specific command. It
>
On Thu, Aug 25, 2016 at 9:58 AM, Lutz Vieweg <l...@5t9.de> wrote:
> On 08/16/2016 01:24 AM, Chris Murphy wrote:
>>
>> On Mon, Aug 15, 2016 at 5:12 PM, Ronan Chagas <roni...@gmail.com> wrote:
>>>
>>> It happened again. The computer was completel
an
xattr to let the allocator know which profile the user wants for the
data, and then to allocate it to the proper existing chunk or create a
new chunk with that profile as needed.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
o it's plausible that some new data goes in old raid0 chunk,
and some old data goes in new single/raid1 chunks.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Aug 24, 2016 at 11:59 AM, Chris Murphy <li...@colorremedies.com> wrote:
> Plugging in the 'btrfs check' reporte backrefs into btrfs-debug-tree
>
> [chris@f24s ~]$ sudo btrfs-debug-tree -b 16913485824 /dev/mapper/brick1
> btrfs-progs v4.7
> checksum verify failed
and not the user. It's sort of annoying that
these messages don't come with any advice what the user is supposed to
do about them.
Curious the found bytes between progs 4.5.3 and 4.6.1 differ... file
system was not mounted in between these checks.
Chris Murphy
--
To unsubscribe from this list: send
at the moment I'm going with the idea
that there's a bug in btrfs check 4.7 that's reporting non-real
problems.
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
[chris@f24s ~]$ sudo btrfs dev stats /brick1
[/dev/mapper/brick1].write_io_errs 0
[/dev/mapper/brick1].read_io_errs0
[/dev/mapper/brick1].flush_io_errs 0
[/dev/mapper/brick1].corruption_errs 0
[/dev/mapper/brick1].generation_errs 0
[chris@f24s ~]$ sudo btrfs scrub status /brick1
scrub
.x that's causing problems silently in normal operation. But it
looks bogus
It always complains about the same backref number, but a different owner number.
--
Chris Murphy
This is a crypto LUKS volume.
cat /proc/mounts
/dev/mapper/brick1 /brick1 btrfs
rw,seclabel,noatime,space_cache,subvolid
se having a WTF moment? Why is the backup_fs_root
generation 6 on all of these backup roots? Doesn't that seem really
unlikely? On all of my filesystems, the fs_root has a lower
generation, but isn't separated by this many generations.
What do you get for:
btrfs-debug-tree -b 29556736 /dev/mapper/V
On Tue, Aug 23, 2016 at 10:05 AM, Chris Murphy <li...@colorremedies.com> wrote:
>btrfs-find-root -d /dev/mapper/VGBIGRAID6-DATA1
I meant to ask for
btrfs-debug-tree -d /dev/...
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrf
r even 52058, 52057, or 52056) is not written or not where
it's supposed to be, and yet the superblock was updated.
>> btrfs-show-super -fa /dev/mapper/VGBIGRAID6-DATA1
Where is this output?
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe lin
uuid: 0397b3eb-fdc4-4d3f-9cc9-d38467dcb6c2
> Total devices 1 FS bytes used 6.72TiB
> devid1 size 16.00TiB used 6.97TiB path
> /dev/mapper/VGBIGRAID6-DATA1
Is it the same md array that these other dataX LV's are on? And they
are mountable?
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t to do unshare. There is a
use case for wanting to set nocow after the fact. I have no idea what
complexity is added on the Btrfs side for either operation, it seems
like at the least to set it, data csum needs a way to be ignored or
removed; and conversely to unset nocow it's a question whether that
mea
On Mon, Aug 22, 2016 at 6:26 PM, Jeff Mahoney <je...@suse.com> wrote:
> On 8/22/16 6:51 PM, Chris Murphy wrote:
>> Trivially reproducible every boot, shortly after mount happens. Also
>> happened with rc2.
>>
>
> Yep. We've disabled this in our kernels. It ca
name+0x3a7/0x3d0
[ 13.309445] [] entry_SYSCALL_64_fastpath+0x1f/0xbd
[ 13.318819] device virbr0-nic left promiscuous mode
[ 13.318854] virbr0: port 1(virbr0-nic) entered disabled state
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a m
0 (Fedora) and I'm not
experiencing problems, let alone this. What is this kernel's
provenance? Is it a plain mainline 4.7.0 that you built? I'm not
really sure what to recommend except maybe going back to 4.5.7 or
4.6.7 as it's a production machine. Heck even 4.4.19 is OK for me in
this regard.
On Sat, Aug 20, 2016 at 1:38 PM, Alberto Bursi <alberto.bu...@outlook.it> wrote:
>
>
> On 08/20/2016 05:21 PM, Chris Murphy wrote:
>>
>> On Fri, Aug 19, 2016 at 10:00 PM, Bearcat Şándor
>> <bearcatsan...@gmail.com> wrote:
>>>
>>> I h
On Sat, Aug 20, 2016 at 9:21 AM, Chris Murphy <li...@colorremedies.com> wrote:
>If you
> deleted this udev rule, you run the risk of some boots sometimes
> having a slightly delayed drive becoming available and the volume
> wrongly being mounted degraded when it's not necessar
RAID permits
assembly of the RAID in firmware, so even the ESP can be mirrored, and
then there's a handoff during boot to the md driver during normal
operation and is managed by mdadm.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the bod
both devices get separately modified while degraded,
it'll corrupt the entire file system. So you're really better off
choosing another solution until Btrfs matures with this use case in
mind.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
help?
>
> I decided to format and reinstall tomorrow. This is a production machine and
> I have to fix this ASAP.
Looks similar to this:
https://lkml.org/lkml/2016/3/28/230
Can you describe the workload happening at the time?
--
Chris Murphy
--
To unsubscribe from this list: send the lin
flush 1, corrupt 0, gen 0
> [337411.704658] BTRFS warning (device sdq): lost page write due to IO
> error on /dev/sdap
>
> /dev/sdap doesn't exist.
OK well
journalctl -b | grep -A10 -B10 "sdap"
See in what other context it appears. And also 'btrfs fi show' and see
if it ap
uot; or also "today" "yesterday" or by
explicit date and time.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
it comes to individual device
allocations. Very clearly Size if really 4, and each device has a 1GiB
chunk. So why not say that? This is consistent with the earlier
"Device allocated" value of 8GiB.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 12, 2016 at 1:37 PM, Chris Murphy <li...@colorremedies.com> wrote:
> On Fri, Aug 12, 2016 at 1:00 PM, Ronan Arraes Jardim Chagas
> <roni...@gmail.com> wrote:
>
> d. Run journalctl -f from a 2nd computer.
Hopefully it's obvious I mean run journalctl -f
On Fri, Aug 12, 2016 at 1:00 PM, Ronan Arraes Jardim Chagas
<roni...@gmail.com> wrote:
> Em Sex, 2016-08-12 às 12:02 -0600, Chris Murphy escreveu:
>> Tons of unallocated space. What kernel messages do you get for the
>> enospc? It sounds like this will be one of the m
g the
file system. There are two additional things you can try: mount with
enospc_debug mount option and see if you can gather more information
about the problem. Or try a 4.8rc1 kernel which as a large number of
enospc changes.
--
Chris Murphy
--
To unsubscribe from this list: send the line &q
th physically destroying the drive for proper disposal,
you can probably forego full disk encryption.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 11, 2016 at 9:11 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Chris Murphy posted on Thu, 11 Aug 2016 14:43:56 -0600 as excerpted:
>
>> On Thu, Aug 11, 2016 at 1:07 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>>> The compression-related problem is
s compressed. The difference is
explained by inline data being compressed (which it is), so I don't
think the fs itself gets compressed.
Chris Murphy
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.o
zo is faster and only a bit less better
compression than zlib, it may be more people choose lzo and that's why
it turns out if there's a problem with compression it happens to be
lzo, coincidence rather than causation. I'm not even sure there's
enough information to have correlation.
--
https://bugzilla.kernel.org/show_bug.cgi?id=151921
btrfs-progs 4.6.1
kernel-4.8.0-0.rc1.git0.1.fc25.x86_64
Details in the bug, which also includes btrfs-debug-tree and
btrfs-image. I haven't tried to reproduce, so it could be a one off,
and there's no enospc_debug mount option used.
--
Chris
problems.
But yes, I like Btrfs snapshots and refinks better. *shrug*
If you find a Btrfs on dmcrypt problem, it's a serious bug, and I
think it would get attention very quickly.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the
nly use restore for the files that are reported by
send/receive as failed due to errors - assuming that even happens. Or
since this is OS stuff, just reinstall the packages for the files
affected by the bad node.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe lin
for much longer than that.
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t
SSD and rerun btrfs check.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Aug 9, 2016 at 6:01 PM, Chris Murphy <li...@colorremedies.com> wrote:
> On Tue, Aug 9, 2016 at 5:15 PM, Matt McKinnon <m...@techsquare.com> wrote:
>> Hello,
>>
>> Our server recently crashed and was rebooted. When it returned our BTRFS
>> volume
output do you get for 'btrfs check' (without
--repair)? If you only get some "errors 400, nbytes wrong" then
--repair should fix the problem.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.k
On Mon, Aug 8, 2016 at 12:38 PM, Ivan Sizov <sivan...@gmail.com> wrote:
> 2016-08-08 20:13 GMT+03:00 Chris Murphy <li...@colorremedies.com>:
>> Just a wild guess, the deletions may be in the tree log and haven't
>> been applied to the other trees (fs tree, extent tree,
I'll guess there's some metadata centric workload, maybe with small
files that are being stored inline, that's filling up the metadata
chunks, leading to enospc.
If changing kernel versions doesn't work, then you'll need to add more
space somehow. The file system is ~90% full anyway.
--
Chris Murph
much. If you don't have
recent snapshots then it's not sanely salvageable, just reinstall.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
help.
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ide text as found in
kernel or journald messages.
And then whatever Austin says.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
. I have no idea to what degree the new enospc code can
help well used existing systems already having enospc issues, vs the
code prevents the problem from happening in the first place. So you
may end up at b. anyway.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe l
when else
this can happen, if it's possible parity is recomputed (and wrongly)
on a normal read, or a balance, or if it's really restricted to scrub.
Another test might be raid 1 or raid10 metadata vs raid56 for data.
That'd probably be more performance related, but there might be some
unexpected behaviors
On Tue, Aug 2, 2016 at 9:38 AM, Chris Murphy <li...@colorremedies.com> wrote:
> Yesterday I saw oom killer knocking off processes during a simple cp
> -a from one Btrfs to another, in a VM, with kernel
> 4.8.0-0.rc0.git3.1.fc25.x86_64. The call trace looks different than
> Marku
though. According ot koji
this is Linux v4.7-6438-gc624c86
This is 'journalctl -o short-monotonic -b-4 -k'
https://drive.google.com/open?id=0B_2Asp8DGjJ9ZC1JSDJnaWpnSEE
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message
p;
btrfs replace start
Only 'btrfs scrub' has status S, and once it gets SIGKILL, it goes Z
and all of its accounting is wrong. But the kernel tasks continue and
appear to complete.
I did all of this with a btrfs raid5, 3 and 4 disks, in a libvirt VM.
---
Chris Murphy
--
To unsubscribe from t
ocalhost.localdomain systemd[1]: Removed slice User
Slice of chris.
Must have something to do with the use of & with balance, which scrub
doesn't need to go to the background.
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a me
On Mon, Aug 1, 2016 at 11:19 AM, Austin S. Hemmelgarn
<ahferro...@gmail.com> wrote:
> On 2016-08-01 13:15, Chris Murphy wrote:
>> I've been using balance with &, and when I logout, the btrfs command
>> continues to flip between status D and R, just like before logout and
On Mon, Aug 1, 2016 at 10:58 AM, Austin S. Hemmelgarn
<ahferro...@gmail.com> wrote:
> On 2016-08-01 12:19, Chris Murphy wrote:
>>
>> On Mon, Aug 1, 2016 at 10:08 AM, Austin S. Hemmelgarn
>> <ahferro...@gmail.com> wrote:
>>
>>>
>>> MD
On Mon, Aug 1, 2016 at 9:26 AM, Chris Mason <c...@fb.com> wrote:
>
>
> On 07/23/2016 04:05 PM, Chris Murphy wrote:
>>
>> Using btrfs-debug-tree, I'm finding something a bit odd about some of
>> the items in this 39P file.
>>
>> Seems normal
>>
On Mon, Aug 1, 2016 at 10:19 AM, Chris Murphy <li...@colorremedies.com> wrote:
> So that makes me wonder how btrfs device add and remove will behave,
> if issued in a DE which is then logged out of. Those commands do not
> return to prompt until they complete.
Strike add. T
ng else (and
> solve the stale scrub status bug too).
OK, I'll update the bug report.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Aug 1, 2016 at 9:46 AM, Chris Murphy <li...@colorremedies.com> wrote:
> - The kernel workers are killed off within ~5 seconds of an
> uninterrupted scrub.
i.e. the kernel workers are doing the same work. They aren't being
killed sooner as a result of logging out from the
' is inconsistent no matter how you look at it. It's a
bug.
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
601 - 700 of 2056 matches
Mail list logo
