Tobias Getzner posted on Thu, 05 Mar 2015 12:48:00 +0100 as excerpted:
I booted back into the graphical system, and when not running Firefox, I
did not get any immediate lock-ups anymore.
I’d welcome any advice on how to proceed, i.e., in how to resolve the
lock-ups, and, if possible, in
I have a btrfs filesystem that gets read errors that appear to only
happen after a disk has been idle a while. I don't know if the error
output below is BTRFS, USB, both or other related. I suspect it's
timing related. If I should take this error report somewhere else,
please point me in the right
Sandy McArthur Jr posted on Thu, 05 Mar 2015 17:04:18 -0500 as excerpted:
I have a btrfs filesystem that gets read errors that appear to only
happen after a disk has been idle a while. I don't know if the error
output below is BTRFS, USB, both or other related. I suspect it's timing
related.
On 02/27/2015 01:37 PM, David Sterba wrote:
Anand reports that the static buffers used for pertty size strings cause
a stack overflow on SPARC. Zach proposed to change the printf format to
wrap the number and the suffix into a macro. This would require to
change all callsites of pretty_size*
When function btrfs_statfs() calculate the tatol size of fs, it is calculating
the total size of disks and then dividing it by a factor. But in some usecase,
the result is not good to user.
Example:
# mkfs.btrfs -f /dev/vdf1 /dev/vdf2 -d raid1
# mount /dev/vdf1 /mnt
# dd
Apparently in my haste, forgot to include any information in my email.
This is also in the URL to the gist of my test script:
btrfs v3.17
Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 GNU/Linux
# mount: /dev/loop2 mounted on /tmp/tmp.FkcW7fRde7.
# Showing mount:
#
Original Message
Subject: Re: btrfs oops while mounting fuzzed btrfs image
From: Liu Bo bo.li@oracle.com
To: Eryu Guan guane...@gmail.com
Date: 2015年03月05日 18:27
On Thu, Mar 05, 2015 at 06:13:54PM +0800, Eryu Guan wrote:
On Thu, Mar 05, 2015 at 05:46:12PM +0800, Liu Bo
Hi there,
Apologies for not confirming on a much more recent kernel, if anyone
could please try my test script for me on a newer kernel that would be
very much appreciated.
I'm working on reproducible builds, and part of this workflow involves
tar archiving parts of read-only btrfs snapshots.
This problem is uncovered by a test case:
http://patchwork.ozlabs.org/patch/244297.
Fsync() can report success when it actually doesn't. When we
have several threads running fsync() at the same tiem and in one fsync() we
get a transaction abortion due to some problems(in the test case it's disk
On Thu, Mar 5, 2015 at 5:36 AM, Liu Bo bo.li@oracle.com wrote:
This problem is uncovered by a test case:
http://patchwork.ozlabs.org/patch/244297.
Fsync() can report success when it actually doesn't. When we
have several threads running fsync() at the same tiem and in one
fsync() we
On Thu, Mar 05, 2015 at 03:09:33PM +0800, Eryu Guan wrote:
Hi,
I was testing btrfs with fsfuzzer and encountered a divide error on
mount, kernel version 3.19 and 4.0-rc1.
I found a similar bug on kernel bugzilla
https://bugzilla.kernel.org/show_bug.cgi?id=88611
Please find the fuzzed
On 3/5/15 3:46 AM, Liu Bo wrote:
On Thu, Mar 05, 2015 at 03:09:33PM +0800, Eryu Guan wrote:
Hi,
I was testing btrfs with fsfuzzer and encountered a divide error on
mount, kernel version 3.19 and 4.0-rc1.
I found a similar bug on kernel bugzilla
Hello,
I had been running kernel 3.19 for a few days now, when yesterday I
started getting hard lock-ups all the time. These seemed to be
correlated to some program activity, most likely to running Firefox. I
downgraded back to 3.18.6, but the problem persisted, though now I only
got soft
On Wed, Mar 04, 2015 at 09:56:28PM -0500, Zygo Blaxell wrote:
rsync seems to get stuck just by reading the same file that extent-same is
acting upon.
Better to give the whole output of dmesg and 'echo w /proc/sysrq-trigger',
we're unable to tell what blocks lock_extent() from the below log
On Thu, Mar 5, 2015 at 2:56 AM, Zygo Blaxell
ce3g8...@umail.furryterror.org wrote:
rsync seems to get stuck just by reading the same file that extent-same is
acting upon.
Mar 4 21:35:08 sneezy kernel: [89798.758960] INFO: task rsync:7425 blocked
for more than 1800 seconds.
Mar 4 21:35:08
On Thu, Mar 05, 2015 at 09:59:09AM +, Filipe David Manana wrote:
On Thu, Mar 5, 2015 at 8:48 AM, Liu Bo bo.li@oracle.com wrote:
This problem is uncovered by a test case:
http://patchwork.ozlabs.org/patch/244297.
Fsync() can report success when it actually doesn't. When we
have
This problem is uncovered by a test case:
http://patchwork.ozlabs.org/patch/244297.
Fsync() can report success when it actually doesn't. When we
have several threads running fsync() at the same tiem and in one fsync() we
get a transaction abortion due to some problems(in the test case it's disk
On Thu, Mar 5, 2015 at 8:48 AM, Liu Bo bo.li@oracle.com wrote:
This problem is uncovered by a test case:
http://patchwork.ozlabs.org/patch/244297.
Fsync() can report success when it actually doesn't. When we
have several threads running fsync() at the same tiem and in one fsync() we
On Thu, Mar 05, 2015 at 06:13:54PM +0800, Eryu Guan wrote:
On Thu, Mar 05, 2015 at 05:46:12PM +0800, Liu Bo wrote:
On Thu, Mar 05, 2015 at 03:09:33PM +0800, Eryu Guan wrote:
Hi,
I was testing btrfs with fsfuzzer and encountered a divide error on
mount, kernel version 3.19 and
On Thu, Mar 5, 2015 at 10:23 AM, Liu Bo bo.li@oracle.com wrote:
On Thu, Mar 05, 2015 at 09:59:09AM +, Filipe David Manana wrote:
On Thu, Mar 5, 2015 at 8:48 AM, Liu Bo bo.li@oracle.com wrote:
This problem is uncovered by a test case:
http://patchwork.ozlabs.org/patch/244297.
On Thu, Mar 05, 2015 at 05:46:12PM +0800, Liu Bo wrote:
On Thu, Mar 05, 2015 at 03:09:33PM +0800, Eryu Guan wrote:
Hi,
I was testing btrfs with fsfuzzer and encountered a divide error on
mount, kernel version 3.19 and 4.0-rc1.
I found a similar bug on kernel bugzilla
If the clone root was not readonly or the dead flag was set on it, we were
leaving without decrementing the root's send_progress counter (and before
we just incremented it). If a concurrent snapshot deletion was in progress
and ended up being aborted, it would be impossible to later attempt to
After we locked the root's root item, a concurrent snapshot deletion
call might have set the dead flag on it. So check if the dead flag
is set and abort if it is, just like we do for the parent root.
Signed-off-by: Filipe Manana fdman...@suse.com
---
fs/btrfs/send.c | 3 ++-
1 file changed, 2
Hello,
Sorry for the long email...
I've found my system locks up when scrubbing with 3.18.x, but not with
3.17.8 across 2 systems.
I have the following BTRFS partitions on system 1:
/ (128GiB, 49GiB used on SSD)
/home (4.2TiB, 624GB used on HDD RAID volume)
I have the following BTRFS
On Tue, Mar 03, 2015 at 07:13:30PM +0800, Dongsheng Yang wrote:
This regression is introduced by two commits:
e339a6b0 (Btrfs: __btrfs_mod_ref should always use no_quota)
1152651a (btrfs: qgroup: account shared subtrees during snapshot delete)
I think you should add more description about
25 matches
Mail list logo
