On Fri, Feb 27, 2015 at 10:32 AM, David Sterba wrote:
>
> + printf("\t-p show converting progress (default)\n");
A quick look a this it looks like you've added a mandatory «option»
since the "case" which handle -p can only turn on this flag. Logic
should be switched to -q for quie
Hi,
just a short update on this topic:
I also tried the Ubuntu 4.0.0-rc1 ppa kernel -> problems are still there.
Luckily kernel 4.0.0-rc2 was released yesterday:
I updated my machine to kernel 4.0.0-rc2 and the problems are gone
(test script has been running fine for about 12 hours now)
Bye,
On Tue, Mar 03, 2015 at 05:35:33PM +0100, David Sterba wrote:
> On Tue, Mar 03, 2015 at 07:02:58PM +0800, Liu Bo wrote:
> > On Mon, Mar 02, 2015 at 12:46:55PM -0500, Josef Bacik wrote:
> > > Dave could hit this assert consistently running btrfs/078. This is
> > > because
> > > when we update the
...
1) qgroup ref operations: instead of tracking qgroup operations through the
delayed refs we simply add new ref operations whenever we notice that we need to
when we've modified the refs themselves.
2) tree mod seq: we no longer have this separation of major/minor counters.
this makes the s
On 02/10/2015 06:24 PM, Dongsheng Yang wrote:
Hi all,
This patchset is based on [Btrfs: qgroup: part-3: bug fixes.]
I am introducing a type to qgroup, then we can get the numbers what we
only care about.
Easy way to get the code for testing:
btrfs: https://yangdongsh...@github.c
On 02/10/2015 06:23 PM, Dongsheng Yang wrote:
Hi all,
This is part2 for qgroup. It is based on
[PATCH 0/9] Btrfs: qgroup: part-1: bug fixes.
[1/4] is reviewed-by Josef.
[2/4] - [4/4] are trying to solve a problem in qgroup reservation.
It would be weired I introduce a may_use in
From: Fabio Estevam
The following build warning is seen when building for ARM:
fs/btrfs/disk-io.c:3927:21: warning: format '%lu' expects argument of type
'long unsigned int', but argument 3 has type 'unsigned int' [-Wformat]
Use the '%zu' specifier when printing 'sizeof'.
Signed-off-by: Fabio
On Tue, Mar 03, 2015 at 09:00:36AM -0500, Josef Bacik wrote:
> On 03/03/2015 06:18 AM, Dongsheng Yang wrote:
>> On 02/26/2015 02:05 PM, Dongsheng Yang wrote:
>>> Wait a minute, this patch seems not working well in accounting quota
>>> number when
>>> deleting data shared by different subvolumes.
>>
On Tue, Mar 03, 2015 at 07:02:58PM +0800, Liu Bo wrote:
> On Mon, Mar 02, 2015 at 12:46:55PM -0500, Josef Bacik wrote:
> > Dave could hit this assert consistently running btrfs/078. This is because
> > when we update the block groups we could truncate the free space, which
> > would
> > try to de
On Wed, Feb 25, 2015 at 07:24:31PM +0100, David Sterba wrote:
> Hi,
>
> a few cleanups that accumulated over time. No real fixes but there are changes
> that may touch functionality (no fstests complaints though).
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git
> cleanups-for
The extent-same ioctl seems to have a locking bug. My test machines
will run between 0 and 3 days before something gets locked and stays
locked forever.
In the dumps and logs below, 'btrsame' calls the btrfs extent-same ioctl
on its arguments. As you can see from the trace, it is stuck in this
v
On Tue, Mar 3, 2015 at 10:31 AM, Quentin Casasnovas
wrote:
Improper arithmetics when calculting the address of the extended ref
could
lead to an out of bounds memory read and kernel panic.
Signed-off-by: Quentin Casasnovas
---
fs/btrfs/tree-log.c | 2 +-
1 file changed, 1 insertion(+), 1
Improper arithmetics when calculting the address of the extended ref could
lead to an out of bounds memory read and kernel panic.
Signed-off-by: Quentin Casasnovas
---
fs/btrfs/tree-log.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git fs/btrfs/tree-log.c fs/btrfs/tree-log.c
in
On Tue, Mar 3, 2015 at 9:38 AM, David Sterba wrote:
Adding linux-btrfs to CC
On Thu, Feb 26, 2015 at 05:00:37PM +0100, Quentin Casasnovas wrote:
Improper arithmetics when calculting the address of the extended
ref could
lead to an out of bounds memory read and kernel panic.
Signed-off-b
Hi,
I have applied the patch but once I start making the kernel, the kernel
oopses and the process freezes. I have removed all of the btrfs mounts
from /etc/fstab and tried with no btrfs filesystems mounted. I still
get the error upon trying to build the kernel! I don't understand how
or w
Adding linux-btrfs to CC
On Thu, Feb 26, 2015 at 05:00:37PM +0100, Quentin Casasnovas wrote:
> Improper arithmetics when calculting the address of the extended ref could
> lead to an out of bounds memory read and kernel panic.
>
> Signed-off-by: Quentin Casasnovas
Good catch.
CC:
Reviewed-by:
On 2015.03.02 at 14:29 +0100, Markus Trippelsdorf wrote:
> On 2015.03.02 at 12:07 +, Filipe David Manana wrote:
> > >> [83159.038708] [ cut here ]
> > >> [83159.038716] WARNING: CPU: 2 PID: 32343 at fs/btrfs/inode.c:8693
> > >> btrfs_destroy_inode+0x278/0x2a0()
> > >> [
On 03/03/2015 06:18 AM, Dongsheng Yang wrote:
On 02/26/2015 02:05 PM, Dongsheng Yang wrote:
Wait a minute, this patch seems not working well in accounting quota
number when
deleting data shared by different subvolumes.
I will investigate more about it and send a V2 out.
I have sent a fstest
When using the fast file fsync code path we can miss the fact that new
writes happened since the last file fsync and therefore return without
waiting for the IO to finish and write the new extents to the fsync log.
Here's an example scenario where the fsync will miss the fact that new
file data ex
On Tue, Mar 03, 2015 at 11:15:17AM +, Filipe David Manana wrote:
> On Tue, Mar 3, 2015 at 12:41 AM, Liu Bo wrote:
> > On Sun, Mar 01, 2015 at 09:08:38AM +, Filipe Manana wrote:
> >> When using the fast file fsync code path we can miss the fact that new
> >> writes happened since the last f
Allow btrfs-convert to use nodesizes other than 4096. It defaults to
max(16384, pagesize), like mkfs. The constant DEFAULT_MKFS_LEAF_SIZE has
been moved to utils.h and renamed to BTRFS_MKFS_DEFAULT_NODE_SIZE for
consistency. convert-tests now test both 4096 and 16384 nodesizes.
Signed-off-by: Seba
This patch passes `make test', and I have also tested the patched
btrfs-convert on populated ext4 filesystems and reverting back again,
without errors; but note that I have very little experience with ext2/3/4
and btrfs, so there is a large possibility that I have missed something.
I'm also a bit u
On 02/26/2015 02:05 PM, Dongsheng Yang wrote:
Wait a minute, this patch seems not working well in accounting quota
number when
deleting data shared by different subvolumes.
I will investigate more about it and send a V2 out.
I have sent a fstest
[PATCH] fstest: btrfs: add a test for quota num
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)
Signed-off-by: Dongsheng Yang
---
tests/btrfs/084 | 84 +
t
On Tue, Mar 3, 2015 at 12:41 AM, Liu Bo wrote:
> On Sun, Mar 01, 2015 at 09:08:38AM +, Filipe Manana wrote:
>> When using the fast file fsync code path we can miss the fact that new
>> writes happened since the last file fsync and therefore return without
>> waiting for the IO to finish and wr
On Tue, Mar 03, 2015 at 08:31:10AM +0100, Marcel Ritter wrote:
> Hi,
>
> yes it is reproducible.
>
> Just creating a new btrfs filesystem (14 disks, data/mdata raid6,
> latest git btrfs-progs)
> and mounting this filesystems causes the system to hang (I think I once even
> got
> it mounted, but
On Mon, Mar 02, 2015 at 12:46:55PM -0500, Josef Bacik wrote:
> Dave could hit this assert consistently running btrfs/078. This is because
> when we update the block groups we could truncate the free space, which would
> try to delete the csums for that range and dirty the csum root. For this to
>
On Mon, Mar 02, 2015 at 12:46:55PM -0500, Josef Bacik wrote:
> Dave could hit this assert consistently running btrfs/078. This is because
> when we update the block groups we could truncate the free space, which would
> try to delete the csums for that range and dirty the csum root. For this to
>
28 matches
Mail list logo