Hi Chris, hi all,
case closed. The reason was that some NVMe devices weren't recognized.
I don't have any idea **why** this happened, but I cleaned out the whole
models tree, made a complete rebuild of the kernel, and now it works.
Sorry for the noise.
And I also switched to dracut on the go, th
Hi Chris,
On Sun, 07 Mar 2021, Chris Murphy wrote:
> I suspect something is wrong with devid 9 in that case. If it's a
> dracut system, then it waits indefinitely for sysroot. You'll need to
> boot with something like rd.break=pre-mount and see first if you can
> mount normally to /sysroot, but if
On Sun, Mar 7, 2021 at 7:18 PM Norbert Preining wrote:
>
> Hi Chris,
>
> once more ..
>
> > > Does the initrd on this system contain?
> > > /usr/lib/udev/rules.d/64-btrfs.rules
>
> No, it didn't.
>
> Now I added it, and with 64-btrfs.rules available in the initrd I still
> get the same error (se
Hi Chris,
once more ..
> > Does the initrd on this system contain?
> > /usr/lib/udev/rules.d/64-btrfs.rules
No, it didn't.
Now I added it, and with 64-btrfs.rules available in the initrd I still
get the same error (see previous screenshot) :-(
Best
Norbert
--
PREINING Norbert
On Sun, Mar 7, 2021 at 5:25 PM Norbert Preining wrote:
>
> Hi
>
> (please cc)
>
> thanks for your email. First some additional information. Since this
> happened I searched and realized that there seem to have been a problem
> with 5.12-rc1, which I tried for short time (checking whether AMD-GPU
>
On Sun, Mar 7, 2021 at 4:28 PM Norbert Preining wrote:
>
> Dear all
>
> (please cc)
>
> not sure this is the right mailing list, but I cannot boot into 5.11.4
> it gives me
> devid 9 uui .
> failed to read the system array: -2
> open_ctree failed
> (only partial, typed
On Sun, Mar 7, 2021 at 6:58 AM Sebastian Roller
wrote:
>
> Would it make sense to just try restore -t on any root I got with
> btrfs-find-root with all of the snapshots?
Yes but I think you've tried this and you only got corrupt files or
files with holes, so that suggests very recent roots are j
Hi
(please cc)
thanks for your email. First some additional information. Since this
happened I searched and realized that there seem to have been a problem
with 5.12-rc1, which I tried for short time (checking whether AMD-GPU
hangs are fixed). Now I read that -rc1 is a btrfs-killer. I have swap
p
Hi,
If this is a boot btrfs filesystem, please try to mount it manually with
a live linux with the kernel 5.11.4?
When a boot btrfs filesystem with multiple disks, I have a question for
a little long time.
If some but not all of the disks are scaned, systemd will try to mount
it? and then btrfs
On Fri, Mar 05, 2021 at 02:36:05PM +0100, David Sterba wrote:
> btrfs-progs version 5.11 have been released.
W: btrfs-progs source: absolute-symbolic-link-target-in-source
ci/images/ci-centos-7-x86_64/docker-build ->
/home/dsterba/labs/btrfs-progs/ci/images/docker-build
W: btrfs-progs source: ab
Dear all
(please cc)
not sure this is the right mailing list, but I cannot boot into 5.11.4
it gives me
devid 9 uui .
failed to read the system array: -2
open_ctree failed
(only partial, typed in from photo)
OTOH, 5.10.19 boots without a hinch
$ btrfs fi show /
Label
On Mon, Feb 22, 2021 at 06:48:18AM -0800, Anand Jain wrote:
> This test case runs fio for raid1/10/1c3/1c4 profiles and all the
> available read policies in the system. At the end of the test case,
> a comparative summary of the result is in the $seqresfull-file.
>
> LOAD_FACTOR parameter controls
On Sun, Mar 07, 2021 at 03:07:43PM +, Filipe Manana wrote:
> On Sun, Mar 7, 2021 at 2:41 PM Eryu Guan wrote:
> >
> > On Thu, Feb 11, 2021 at 05:01:18PM +, fdman...@kernel.org wrote:
> > > From: Filipe Manana
> > >
> > > Test cases where a direct IO write, with O_DSYNC, can not be done and
On Sun, Mar 7, 2021 at 2:41 PM Eryu Guan wrote:
>
> On Thu, Feb 11, 2021 at 05:01:18PM +, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > Test cases where a direct IO write, with O_DSYNC, can not be done and has
> > to fallback to a buffered write.
> >
> > This is motivated by a re
On Thu, Feb 11, 2021 at 05:01:18PM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Test cases where a direct IO write, with O_DSYNC, can not be done and has
> to fallback to a buffered write.
>
> This is motivated by a regression that was introduced in kernel 5.10 by
> commit 0eb7929
> > > I don't know. The exact nature of the damage of a failing controller
> > > is adding a significant unknown component to it. If it was just a
> > > matter of not writing anything at all, then there'd be no problem. But
> > > it sounds like it wrote spurious or corrupt data, possibly into
> > >
From: Filipe Manana
[ Upstream commit 20903032cd9f0260b99aeab92e6540f0350e4a23 ]
During the nocow writeback path, we currently iterate the rbtree of block
groups twice: once for checking if the target block group is RO with the
call to btrfs_extent_readonly()), and once again for getting a nocow
From: Qu Wenruo
[ Upstream commit c28ea613fafad910d08f67efe76ae552b1434e44 ]
[BUG]
When running fstresss, we can hit strange data csum mismatch where the
on-disk data is in fact correct (passes scrub).
With some extra debug info added, we have the following traces:
0482us: btrfs_do_readpage:
18 matches
Mail list logo
