On Tue, 2014-10-28 at 16:42 +0800, Anand Jain wrote:
>
>
> On 28/10/2014 12:03, Gui Hecheng wrote:
> > On Thu, 2014-10-23 at 21:36 +0800, Anand Jain wrote:
> >>
> >>there is no point in re-creating so many btrfs kernel's logic in user
> >>space. its just unnecessary, when kernel is alread
On 28/10/2014 12:03, Gui Hecheng wrote:
On Thu, 2014-10-23 at 21:36 +0800, Anand Jain wrote:
there is no point in re-creating so many btrfs kernel's logic in user
space. its just unnecessary, when kernel is already doing it. use
some interface to get info from kernel after device is
On Thu, 2014-10-23 at 21:36 +0800, Anand Jain wrote:
>
> there is no point in re-creating so many btrfs kernel's logic in user
> space. its just unnecessary, when kernel is already doing it. use
> some interface to get info from kernel after device is registered,
> (not necessarily mounted
On Thu, 2014-10-23 at 15:23 +0200, Petr Janecek wrote:
> Hello Gui,
>
> > Oh, it seems that there are btrfs with missing devs that are bringing
> > troubles to the @open_ctree_... function.
>
> what do you mean by "missing devs"? I have no degraded fs.
Ah, sorry, I'm too focused on the problem
there is no point in re-creating so many btrfs kernel's logic in user
space. its just unnecessary, when kernel is already doing it. use
some interface to get info from kernel after device is registered,
(not necessarily mounted). so progs can be as sleek as possible.
to me it started as jus
Hello Gui,
> Oh, it seems that there are btrfs with missing devs that are bringing
> troubles to the @open_ctree_... function.
what do you mean by "missing devs"? I have no degraded fs.
The time "btrfs fi sh" spends scanning disks of a filesystem seems to
be proportional to the amount of dat
On Thu, 2014-10-23 at 16:13 +0800, Anand Jain wrote:
>
> Some of the disks on my system were missing and I was able to hit
> this issue.
>
>
>
> Check tree block failed, want=12582912, have=0
> read block failed check_tree_block
> Couldn't read chunk root
> warning devid 2 not f
Some of the disks on my system were missing and I was able to hit
this issue.
Check tree block failed, want=12582912, have=0
read block failed check_tree_block
Couldn't read chunk root
warning devid 2 not found already
Check tree block failed, want=143360, have=0
read block fa
Hello,
> You have mentioned two issues when balance and fi show running
> concurrently
my mail was a bit chaotic, but I get the stalls even on idle system.
Today I got
parent transid verify failed on 1559973888000 wanted 1819 found 1821
parent transid verify failed on 1559973888000 wanted 18
Hi,
You have mentioned two issues when balance and fi show running
concurrently
- stalling and
- errors.
first of all..
3.17 replaced our own system wide disk scan methods by lblkid scan
methods. lblkid with its feature-rich is slower as reported here.
https://www.mail-archive.com/linux
Hello,
one more thing: I just overwrote part of one disk.
"btrfs filesystem show" could be more helpful diagnosing this:
# btrfs fi sh
Label: 'BTRFSROOT' uuid: d877125e-9b8d-47ea-b57b-7411292fd26c
Total devices 1 FS bytes used 2.91GiB
devid1 size 29.44GiB used 5.04GiB pa
Hello,
> the version 3.17 of btrfs-progs has been released.
on a system with 3-disk raid1 and 4 and 5-disk raid10 fs,
"btrfs filesystem show" now stalls for approx. half a minute after the
listing, just before the version information. During that time, it
often prints something like
[...]
Hi,
the version 3.17 of btrfs-progs has been released.
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git v3.17
https://www.kernel.org/pub/linux/kernel/people/kdave/btrfs-progs/btrfs-progs-v3.17.tar.xz
Among other fixes and updates, there are many fsck improvements, most notably
13 matches
Mail list logo
