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 if=
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* an
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
Original Message
Subject: Re: btrfs oops while mounting fuzzed btrfs image
From: Liu Bo
To: Eryu Guan
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 wrote:
On Thu, Mar 05, 2015 at 03:09:
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 partit
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:
# /tmp/tmp.
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. Pro
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, i
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
> relate
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
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
>>
>> https://bugzilla.kernel.org/
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
dele
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
---
fs/btrfs/send.c | 3 ++-
1 file changed, 2 insertions(+), 1 del
On Thu, Mar 5, 2015 at 5:36 AM, Liu Bo 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
get a transaction abort
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 lock-ups
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 10:23 AM, Liu Bo 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 wrote:
>> > This problem is uncovered by a test case:
>> > http://patchwork.ozlabs.org/patch/244297.
>> >
>> > Fsync() can report succes
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
On Thu, Mar 05, 2015 at 09:59:09AM +, Filipe David Manana wrote:
> On Thu, Mar 5, 2015 at 8:48 AM, Liu Bo 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 t
On Thu, Mar 5, 2015 at 2:56 AM, Zygo Blaxell
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 sneezy kernel: [89798.759
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
> >
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 8:48 AM, Liu Bo 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
> get a transaction
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 t
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
25 matches
Mail list logo