ks and the btrfs snapshot
> functionality breaks.
I don't see how this is even possibly related. Furthermore, "btrfs fi show" as
well as snapshots seem to work just fine for me.
That being said, I've given up on running a 32-bit userspace, so I don't
really care if this bugfix gets reverte
At 06/01/2016 12:23 AM, David Sterba wrote:
On Tue, May 31, 2016 at 03:27:42PM +0800, luke wrote:
+static void ref_root_fini(struct ref_root *ref_tree)
+{
+ struct ref_node *node;
+ struct rb_node *next;
+
+ while ((next = rb_first(_tree->rb_root)) != N
At 06/01/2016 03:51 AM, Mark Fasheh wrote:
Thanks for this test.
On Tue, May 31, 2016 at 10:03:54AM +0800, Lu Fengqi wrote:
+echo "Start balance" >>$seqres.full
+_btrfs_stress_balance -d $SCRATCH_MNT >/dev/null 2>&1 &
+balance_pid=$!
+
+# 30s is enough to trigger bug
+sleep
At 06/01/2016 12:01 AM, David Sterba wrote:
On Tue, May 31, 2016 at 03:14:25PM +0800, luke wrote:
@@ -68,6 +68,12 @@ struct meta_cluster {
struct fs_chunk {
u64 logical;
u64 physical;
+ /* physical_dup only store additonal physical for BTRFS_BLOCK_GROUP_DUP
At 06/01/2016 12:15 AM, David Sterba wrote:
On Tue, May 31, 2016 at 11:08:39AM +0800, luke wrote:
+};
+
+/* dynamically allocate and initialize a ref_root */
+static struct ref_root *ref_root_alloc(gfp_t gfp_mask)
+{
+ struct ref_root *ref_tree;
+
+ ref_tree = kmalloc(sizeof
At 05/31/2016 05:18 PM, Filipe Manana wrote:
On Tue, May 31, 2016 at 10:08 AM, luke <lufq.f...@cn.fujitsu.com> wrote:
At 05/31/2016 03:39 PM, Filipe Manana wrote:
On Tue, May 31, 2016 at 3:03 AM, Lu Fengqi <lufq.f...@cn.fujitsu.com> wrote:
Test if qgroup can handle
Does anyone have interest in this patch?
在 2016年05月16日 11:23, Lu Fengqi 写道:
Only in the case of different root_id or different object_id, check_shared
identified extent as the shared. However, If a extent was referred by
different offset of same file, it should also be identified as shared.
In
in
general.
> I think, my suggested patch does not change any working ABI, and no change
> to the user space tools are necessary.
Don't the user space tools need to call a different ioctl?
Luke
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday, October 29, 2015 2:39:32 PM David Sterba wrote:
> On Thu, Oct 29, 2015 at 08:22:34AM +0000, Luke Dashjr wrote:
> > > In what way is SEND broken? There are only u64/s64 members in
> > > btrfs_ioctl_send_args, I don't see how this could break on 32/64
&
On Friday, May 15, 2015 11:19:22 AM David Sterba wrote:
> On Thu, May 14, 2015 at 04:27:54PM +0000, Luke Dashjr wrote:
> > On Thursday, May 14, 2015 2:06:17 PM David Sterba wrote:
> > > On Wed, May 13, 2015 at 05:15:26PM +, Luke Dashjr wrote:
> > > > 32-bi
32-bit ioctl uses these rather than the regular FS_IOC_* versions. They can
be handled in btrfs using the same code. Without this, 32-bit {ch,ls}attr
fail.
Signed-off-by: Luke Dashjr <luke-jr+...@utopios.org>
Cc: sta...@vger.kernel.org
---
fs/btrfs/ctree.h | 1 +
fs/btrfs/file.c | 2
Hi,
I'm having the same issues as previously mentioned.
Apparently the new fsck tool will be able to recover this?
Few questions, is there a GIT version I can compile and use already for this?
If not, is there any indication of when this will be released?
---
Luke Sheldrick
e: l
12 matches
Mail list logo