You are correct, I tried to put all the error handling code in separate layer,
but if there is no need to print error for each system call then it does not
make sense to integrate this path.
One of the userspace project on
https://btrfs.wiki.kernel.org/index.php/Project_ideas#Userspace_tools_proje
'mount degraded,ro'
see if there is any non-zero non-raid1 group profile.
On 10/29/14 04:32, Zack Coffey wrote:
Revisit of a previous issue. Setup a single 640GB drive with BTRFS and
compression. This was not a system drive, just a place to put random
junk.
Made a RAID1 with another driv
this is (most likely) due to patch below,
commit 915902c5002485fb13d27c4b699a73fb66cc0f09
btrfs-progs: fix device missing of btrfs fi show with seed devices
Could you try to back out the patch from progs and give it a shot ?
and pls report what you see. T
Juan Orti posted on Tue, 28 Oct 2014 16:54:19 +0100 as excerpted:
> [ 3713.086292] BTRFS: unable to fixup (regular) error at logical
> 483011874816 on dev /dev/sdb2
> [ 3713.092577] BTRFS: checksum error at logical 483011948544 on dev
> /dev/sdb2, sector 628793528, root 2500, inode 1436631, offs
Original Message
Subject: Re: read block failed check_tree_block / Couldn't read chunk tree
From: Rene Thomas
To: Qu Wenruo
Date: 2014年10月28日 18:59
Ok. That's not what I want to hear but bad thinks happens sometimes :-(
Only for understanding. Recover means to get the RAID b
On 10/28/14 9:19 PM, Chris Murphy wrote:
> 3.18.0-0.rc2.git1.1.fc22.x86_64
> btrfs-progs-3.17-1.fc21.x86_64
>
> # btrfs fi show /mnt
> Label: 'btrfs1' uuid: 0f1c615f-30a0-4166-8a3c-987849551513
> Total devices 2 FS bytes used 233.54GiB
> devid1 size 465.76GiB used 236.03GiB path /
3.18.0-0.rc2.git1.1.fc22.x86_64
btrfs-progs-3.17-1.fc21.x86_64
# btrfs fi show /mnt
Label: 'btrfs1' uuid: 0f1c615f-30a0-4166-8a3c-987849551513
Total devices 2 FS bytes used 233.54GiB
devid1 size 465.76GiB used 236.03GiB path /dev/sdb
devid2 size 298.09GiB used 236.
If right after starting the snapshot creation ioctl we perform a write against a
file followed by a truncate, with both operations increasing the file's size, we
can get a snapshot tree that reflects a state of the source subvolume's tree
where
the file truncation happened but the write operation
Duncan <1i5t5.duncan cox.net> writes:
[..]
>
> Hope that helps! =:^)
>
Thanks a lot for that many hints!
Unfortunately, btrfs restore does not find the tree root and so it does not
find anything.
I will wait for Qu Wenruo to enhance chunk-recovering.
And in the meantime I will test openSUSE 1
Am 28.10.14 um 02:40 schrieb Qu Wenruo:
Original Message
Subject: Re: btrfs unmountable: read block failed check_tree_block;
Couldn't read tree root
From: Qu Wenruo
To: Ansgar Hockmann-Stolle ,
Date: 2014年10月28日 09:05
Original Message
Subject: Re: btrfs un
Revisit of a previous issue. Setup a single 640GB drive with BTRFS and
compression. This was not a system drive, just a place to put random
junk.
Made a RAID1 with another drive of just the metadata. Was in
that state for less than 12 hours-ish, removed the second drive and
now cannot get to any
Revisit of a previous issue. Setup a single 640GB drive with BTRFS and
compression. This was not a system drive, just a place to put random
junk.
Made a RAID1 with another drive of just the metadata. Was in
that state for less than 12 hours-ish, removed the second drive and
now cannot get to any d
El mar, 28-10-2014 a las 16:54 +0100, Juan Orti escribió:
> I'm seeing these errors in a RAID1 fs:
> (...)
> Why can't it fix the errors? a bad device? smartctl says the disk is ok.
> I'm currently running a full scrub to see if it finds more errors. What
> should I do?
>
Well, the scrub has fi
Hello,
[...]
> This patch seems to fix https://bugzilla.kernel.org/show_bug.cgi?id=64961
> for me: I've been testing it together with
> [PATCH] Btrfs: fix invalid leaf slot access in btrfs_lookup_extent()
> on top of 3.18-rc2 since yesterday, and so far no crashes during balance
> or device remo
On Tue, Oct 28, 2014 at 9:33 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> Since it's not an option here I've not looked into it too closely
> personally, and don't know if it'll fit your needs, but if it does, it
> may well be simpler to substitute it into the existing backup setup
> without rewritin
Hi, it seems that when using rtorrent to download into a btrfs system,
it leads to the creation of files that fail to read properly.
For instance, I get rtorrent to crash, but if I try to rsync the file he
was writting into someplace else, rsync also fails with the message
"can't map file "$file":
3.16.6-203.fc20.x86_64+debug
Doing a scrub on a raid1 volume, directly formatted 2 plain unpartitioned HDDs.
Every now and then I get a message:
[ 613.056923] kworker/dying (6) used greatest stack depth: 10600 bytes left
This doesn't happen when I'm not doing scrubs. It doesn't happen with kerne
I'm seeing these errors in a RAID1 fs:
[ 3565.073223] BTRFS: bdev /dev/sdb2 errs: wr 0, rd 0, flush 0, corrupt
30, gen 0
[ 3565.073472] BTRFS: unable to fixup (regular) error at logical
460632743936 on dev /dev/sdb2
[ 3566.605419] BTRFS: checksum error at logical 461883383808 on dev
/dev/sdb2,
On Wed, Oct 15, 2014 at 08:50:38AM +0800, Anand Jain wrote:
> -void btrfs_register_one_device(char *fname)
> +int btrfs_register_one_device(char *fname)
> -void btrfs_register_one_device(char *fname);
> +int btrfs_register_one_device(char *fname);
JFYI, I changed 'char' to 'const char'.
--
To uns
Hi,
without any explanation I can only speculate what's the purpose of this
patch. I can see it hides the basic syscalls to wrappers and prints
messages in case of an error value.
Currently, the error codes are mostly handled and the error messages are
printed as needed, we don't want to see all
On Tue, Oct 28, 2014 at 9:12 AM, E V wrote:
> I've seen dead locks on 3.16.3. Personally, I'm staying with 3.14
> until something newer stabilizes, haven't had any issues with it. You
> might want to try the latest 3.14, though I think there should be a
> new one pretty soon with quite a few btrfs
Stephan Alz posted on Tue, 28 Oct 2014 12:33:12 +0100 as excerpted:
> And about the "data not being important to backed up", hell yes it is so
> yesterday I did a "backup of the backups" to a good old XFS filesystem
> (something which is reliable).
Makes sense. FWIW, my second backup is to reise
I've seen dead locks on 3.16.3. Personally, I'm staying with 3.14
until something newer stabilizes, haven't had any issues with it. You
might want to try the latest 3.14, though I think there should be a
new one pretty soon with quite a few btrfs patches.
On Tue, Oct 28, 2014 at 7:33 AM, Stephan A
Hello,
>On Mon, 27 Oct 2014 13:44:22 +, Filipe David Manana wrote:
>> On Mon, Oct 27, 2014 at 12:11 PM, Filipe David Manana
>> wrote:
>>> On Mon, Oct 27, 2014 at 11:08 AM, Miao Xie wrote:
On Mon, 27 Oct 2014 09:19:52 +, Filipe Manana wrote:
> We have a race that can lead us to m
Hello Folks,
Thanks for the help what I got so far. I did what you have recommended and
upgraded the kernel to 3.16.
After reboot it automatically resumed the balancing operation. For about 2
hours it went well:
Label: 'backup' ...
Total devices 5 FS bytes used 5.81TiB
devid 1 size
On Mon, Oct 27, 2014 at 7:57 PM, Chris Mason wrote:
> On Tue, Oct 21, 2014 at 6:12 AM, Filipe Manana wrote:
>>
>> If right after starting the snapshot creation ioctl we perform a write
>> against a
>> file followed by a truncate, with both operations increasing the file's
>> size, we
>> can get a
On Mon, Oct 27, 2014 at 6:33 PM, Hugo Mills wrote:
> On Mon, Oct 27, 2014 at 11:21:13AM -0700, Christian Kujau wrote:
>> On Mon, 27 Oct 2014 at 16:35, David Sterba wrote:
>> > Yeah sorry, I sent the v2 too late, here's an incremental that applies
>> > on top of current 3.18-rc
>> >
>> > https://pa
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
Original Message
Subject: Re: read block failed check_tree_block / Couldn't read chunk tree
From: Rene Thomas
To: Qu Wenruo ,
Date: 2014年10月28日 14:59
Yes, removed sdb as well. Got the same error.
You are right. I miss to add the btrfs ml when I reply. Thanks.
I'am looking f
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
30 matches
Mail list logo
