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:
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
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 quentin.casasno...@oracle.com
---
fs/btrfs/tree-log.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
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
On Tue, Mar 3, 2015 at 9:38 AM, David Sterba dste...@suse.cz 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
On Tue, Mar 3, 2015 at 10:31 AM, Quentin Casasnovas
quentin.casasno...@oracle.com 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 quentin.casasno...@oracle.com
---
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 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 it did
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 Tue, Mar 3, 2015 at 12:41 AM, Liu Bo bo.li@oracle.com 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
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 yangds.f...@cn.fujitsu.com
---
tests/btrfs/084 | 84
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 delete the
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-4.1
On Tue, Mar 03, 2015 at 11:15:17AM +, Filipe David Manana wrote:
On Tue, Mar 3, 2015 at 12:41 AM, Liu Bo bo.li@oracle.com 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
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
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.
I will
On Fri, Feb 27, 2015 at 10:32 AM, David Sterba dste...@suse.cz 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
From: Fabio Estevam fabio.este...@freescale.com
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
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
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 block
...
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
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:
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 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()
[83159.038718]
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
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
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
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 quentin.casasno...@oracle.com
Good
28 matches
Mail list logo
