Dear all,
when trying to replace a device of a file system for which a balance is
running, btrfs-progs fails with the error message:
ERROR: ioctl(DEV_REPLACE_START) on '/mnt/xyz' returns error:
This might also be true for alike operations, such as "add", "delete"
and "resize", since those cases
Hi Imran,
On 11/15/2017 09:51 AM, Imran Geriskovan wrote as excerpted:
> Any further advices?
you might be interested in the thread "Read before you deploy btrfs +
zstd"¹.
Cheers,
Lukas
¹ https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg69871.html
--
To unsubscribe from this list: s
On 11/01/2017 03:05 PM, ST wrote as excerpted:
>> However, it's important to know that if your users have shell access,
>> they can bypass qgroups. Normal users can create subvolumes, and new
>> subvolumes aren't added to an existing qgroup by default (and unless I'm
>> mistaken, aren't constra
On 09/26/2017 11:36 AM, Qu Wenruo wrote as excerpted:
> This is strange, this means that we can't find a chunk map for a 72K
> length data extent.
>
> Either the new mapper code has some bug, or it's a big problem.
> But I think it's more possible for former case.
>
> Would you please try to dump
Hi Qu,
On 09/26/2017 10:51 AM, Qu Wenruo wrote as excerpted:
> This make things more weird.
> Just in case, are you executing offline scrub by "btrfs scrub start
> --offline "
Yes. I even got some output (pretty sure the last lines are missing due
to the crash):
WARNING: Offline scrub doesn't su
Dear Qu,
thanks for your reply.
On 09/25/2017 12:19 PM, Qu Wenruo wrote as excerpted:
> Even no dmesg output using tty or netconsole?
And thanks for the pointer to netconsole, I tried that one.
No success. I set netconsole up, verified it worked, started a scrub,
the machine went away after a co
On 09/25/2017 06:11 PM, linux-bt...@oh3mqu.pp.hyper.fi wrote as excerpted:
> After a long googling (about more complex situations) I suddenly
> noticed "device sdb" WTF??? Filesystem is mounted from /dev/md3 (sdb
> is part of that mdraid) so btrfs should not even know anything about
> that /dev/sd
Dear all,
I experience reproducible OS crashes when scrubbing a btrfs file system.
Apart from that, the file system mounts rw and is usable without any
problems (including modifying snapshots and all that).
When the system crashes (i.e., freezes), there are no errors printed to
the system logs or
On 11/20/2015 10:04 AM, Lukas Pirl wrote as excerpted:
> I am (still) trying to recover a RAID1 that can only be mounted
> recovery,degraded,ro.
>
> I experienced an issue that might be interesting for you: I tried to
> mount the file system rw,recovery and the kernel ended up bur
On 12/07/2015 02:57 PM, Alistair Grant wrote as excerpted:
> Fixing recursive fault, but reboot is needed
For the record:
I saw the same message (incl. hard lockup) when doing a balance on a
single-disk btrfs.
Besides that, the fs works flawlessly (~60GB, usage: no snapshots, ~15
lxc containers,
On 11/27/2015 04:11 PM, Duncan wrote as excerpted:
> My big hesitancy would be over that fact that very few will run or test
> mixed-mode at TB scale filesystem level, and where they do, it's likely
> to be in ordered to work around the current (but set to soon be
> eliminated) metadata-only (no
Hi Ian,
On 11/27/2015 08:42 PM, Ian Kelling wrote as excerpted:
> Great info, thanks. Just trying to write a file, sync and read it
> sounds like the easiest test for now, especially since I don't
> know what the write fail log entries will look like. And setting
> up SMART notifications.
SMART n
Dear list,
if a larger RAID file system (say disk space of 8 TB in total) is
created in mixed mode, what are the implications?
>From reading the mailing list and the Wiki, I can think of the following:
+ less hassle with "false positive" ENOSPC
- data and metadata have to have the same replicati
On 11/21/2015 10:01 PM, Alexander Fougner wrote as excerpted:
> This is fixed in btrfs-progs 4.3.1, that allows you to delete a
> device again by the 'missing' keyword.
Thanks Alexander! I just found the thread reporting the bug but not the
patch with the corresponding btrfs-tools version it was m
On 11/21/2015 08:16 PM, Duncan wrote as excerpted:
> Lukas Pirl posted on Sat, 21 Nov 2015 13:37:37 +1300 as excerpted:
>
>> > Can "btrfs_recover_relocation" prevented from being run? I would not
>> > mind losing a few recent writes (what was a balance) but ins
On 11/21/2015 01:47 PM, Qu Wenruo wrote as excerpted:
> Hard to say, but we'd better keep an eye on this issue.
> At least, if it happens again, we should know if it's related to
> something like newer kernel or snapshots.
I can confirm the initially describe behavior of "btrfs check" and
reading
a block device
Thanks and best regards,
Lukas
On 11/20/2015 10:04 PM, Lukas Pirl wrote as excerpted:
> Dear list,
>
> I am (still) trying to recover a RAID1 that can only be mounted
> recovery,degraded,ro.
>
> I experienced an issue that might be interesting for you: I tried t
Dear list,
I am (still) trying to recover a RAID1 that can only be mounted
recovery,degraded,ro.
I experienced an issue that might be interesting for you: I tried to
mount the file system rw,recovery and the kernel ended up burning one
core (and only one specific core, never scheduled to another
On 11/20/2015 12:59 PM, Hugo Mills wrote as excerpted:
>Nothing actively wrong with that, no. It certainly won't break
> anything. It's just rarely actually useful. The usual situation is
> that you run out of one kind of storage before the other (data vs
> metadata, that is), and you need to f
Hi list,
I rarely see balance used with -dusage -musage together, esp. with
values other than zero.
The question is, is there anything wrong with running (say) `balance
-dusage=50 -musage=30` regularly?
Thanks and best regards,
Lukas
--
To unsubscribe from this list: send the line "unsubscribe
Thanks for the answers Duncan, Hugo and Austin.
I'll try a recovery as soon as I can and might (probably) come back to
the list then.
On 10/30/2015 11:58 PM, Duncan wrote:
> Meanwhile, this does reinforce the point that snapshots don't
> replace full backups, that being the reason I don't use the
TL;DR: thanks but recovery still preferred over recreation.
Hello Duncan and thanks for your reply!
On 10/26/2015 09:31 PM, Duncan wrote:
FWIW... Older btrfs userspace such as your v3.17 is "OK" for normal
runtime use, assuming you don't need any newer features, as in normal
runtime, it's the k
TL;DR: RAID1 does not recover, I guess the interesting part in the stack
trace is:
Call Trace:
[] __del_reloc_root+0x30/0x100 [btrfs]
[] free_reloc_roots+0x25/0x40 [btrfs]
[] merge_reloc_roots+0x18e/0x240 [btrfs]
[] btrfs_recover_relocation+0x374/0x420 [btrfs]
[] open_ctree+0x1b7d/0x
23 matches
Mail list logo