We won't change commit root, skip locking dance with commit root
when walking backrefs, this can speed up btrfs send operations.
Signed-off-by: Wang Shilong
---
fs/btrfs/backref.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index
Add missing test for btrfs quota groups feature,test idea is to create
a parent qgroup that groups some subvolume groups, we try to write
some data into every subvolume and then check if we exceed parent
qgroup's limit size.
Signed-off-by: Wang Shilong
---
tests/btrfs/039 | 94 ++
The usage() in help.c calls exit(1), so the break behind is nonsense
and should be removed.
Signed-off-by: Gui Hecheng
---
cmds-property.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/cmds-property.c b/cmds-property.c
index 3d1f18c..df53f91 100644
--- a/cmds-property.c
+++ b/cmds-property.
To be consistent with the other cmds, replace the warning msg
with usage() when send/receive are used without any args.
Signed-off-by: Gui Hecheng
---
cmds-receive.c | 6 ++
cmds-send.c| 7 ++-
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/cmds-receive.c b/cmds-recei
The "ret" will be soon used to hold the return value of another function,
assign -1 to it before is nonsense.
Signed-off-by: Gui Hecheng
---
free-space-cache.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/free-space-cache.c b/free-space-cache.c
index 55d7318..bddde24 100644
--- a/free-sp
So this is a stress test for btrfs quota operations. it can also
detect the following commit fixed problem:
4082bd3d73(Btrfs: fix oops when writting dirty qgroups to disk)
Signed-off-by: Wang Shilong
---
tests/btrfs/040 | 75 +
tests/btrfs
Test flow is to run fsstress after triggering quota rescan.
the ruler is simple, we just remove all files and directories,
sync filesystem and see if qgroup's ref and excl are nodesize.
Signed-off-by: Wang Shilong
---
tests/btrfs/038 | 75 +
Add close_ctree()s before the "returns" on errors after open_ctree()
Signed-off-by: Gui Hecheng
---
cmds-check.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/cmds-check.c b/cmds-check.c
index 2911af0..81f65a3 100644
--- a/cmds-check.c
+++ b/cmds-check.c
@@ -6460,6 +
Hi Kostia,
On 02/12/2014 04:09 AM, Kostia Khlebopros wrote:
> Any plans on having "brtfs fi df" report more precise values rather
> then rounded off to the nearest hundredth of a unit. full
> kilobytes(1024 bytes =1Kib) or in bytes would be nice>
> Current output:
>
> # btrfs fi df /data
> Data,
Hi Hugo,
On 02/11/2014 07:56 PM, Hugo Mills wrote:
>> $ sudo btrfs filesystem df /mnt/btrfs1/
>> Disk size:400.00GB
>> Disk unallocated: 391.97GB
>> Disk allocation:
>> AllocatedUsed
>>Data, single: 2.01GB, 1.00GB
>>System, DUP
On Feb 12, 2014, at 10:13 AM, Saint Germain wrote:
> On 11 February 2014 19:15, Chris Murphy wrote:
>>>
>>> To summarize, I think I have 3 options for partitioning (I am not
>>> considering UEFI secure boot or swap):
>>> 1) grub, BTRFS partition (i.e. full disk in BTRFS), /boot inside BTRFS
>
On 11 February 2014 21:35, Duncan <1i5t5.dun...@cox.net> wrote:
> Saint Germain posted on Tue, 11 Feb 2014 11:04:57 +0100 as excerpted:
>
>> The big problem I currently have is that based on your input, I hesitate
>> a lot on my partitioning scheme: should I use a dedicated /boot
>> partition or sh
On 11 February 2014 19:15, Chris Murphy wrote:
>>
>> To summarize, I think I have 3 options for partitioning (I am not
>> considering UEFI secure boot or swap):
>> 1) grub, BTRFS partition (i.e. full disk in BTRFS), /boot inside BTRFS
>> subvolume
>
> This doesn't seem like a good idea for a boot
On Wed, Feb 12, 2014 at 05:01:23PM +0100, David Sterba wrote:
> On Fri, Feb 07, 2014 at 10:20:10AM +, Hugo Mills wrote:
> > On Fri, Feb 07, 2014 at 06:08:56PM +0800, Anand Jain wrote:
> > > mainly here sysfs way defeats the purpose - debug as
> > > mentioned. Sysfs would/should show only moun
On Fri, Feb 07, 2014 at 10:20:10AM +, Hugo Mills wrote:
> On Fri, Feb 07, 2014 at 06:08:56PM +0800, Anand Jain wrote:
> > mainly here sysfs way defeats the purpose - debug as
> > mentioned. Sysfs would/should show only mounted disks,
>
>So let's find a way of showing the "known-about" da
The argument last wasn't used, all callers supplied a NULL value
for it. Also removed unnecessary intermediate storage of the result
of key comparisons.
Signed-off-by: Filipe David Borba Manana
---
fs/btrfs/delayed-ref.c | 24 ++--
1 file changed, 6 insertions(+), 18 deleti
When we didn't find the exact ref head we were looking for, if
return_bigger != 0 we set a new search key to match either the
next node after the last one we found or the first one in the
ref heads rb tree, and then did another full tree search. For both
cases this ended up being pointless as we wo
When we split an extent state there's no need to start the rbtree search
from the root node - we can start it from the original extent state node,
since we would end up in its subtree if we do the search starting at the
root node anyway.
Signed-off-by: Filipe David Borba Manana
---
fs/btrfs/exte
On Wednesday 12 February 2014 11:32:30 Pavel Volkov wrote:
> On Monday 10 February 2014 16:13:40 Josef Bacik wrote:
> > Build a kernel with this patch applied
> >
> > http://ur1.ca/glslj
> >
> > and re-run the mount and when it fails attach dmesg to this email.
> > Thanks,
> >
> > Josef
>
> No
On Wed, Feb 12, 2014 at 05:46:02AM -0800, Marc MERLIN wrote:
> Does anyone know who the maintainer to send bug reports to, is?
g2p.c...@gmail.com
https://github.com/g2p/bedup
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel
On Wed, Feb 12, 2014 at 10:18:26AM +0800, Qu Wenruo wrote:
> Please ignore this patchset since adding a new option to
> find_mount_root is not the best method to solve the problem.
I'll merge the first patch, it's moving a utility finction to a file
where it IMO belongs.
--
To unsubscribe from thi
So, I've veen running this for a few weeks, and soon should have
something half decent to share for others to use.
Unfortunately, one of my backups is now failing like so:
btrfs send -p "$src_snap" "$src_newsnap" | btrfs receive "$dest_pool/"
+ btrfs send -p /mnt/btrfs_pool1/home_ro.20140209_12:0
Does anyone know who the maintainer to send bug reports to, is?
On Sat, Feb 08, 2014 at 09:19:36PM -0800, Marc MERLIN wrote:
> kernel 3.12.7, python 2.7.6-5, debian testing/unstable, bedup installed as per
> pip install --user bedup
>
> I tried installing the git version, but the error is the sam
Anand Jain posted on Wed, 12 Feb 2014 15:36:48 +0800 as excerpted:
>> BTW, another (general) reason over-mounts are sometimes used is to
>> deliberately obscure what's underneath. It's worth noting that
>> anything with a file already open on the underlying filesystem still
>> has access to that
On Wed, Feb 12, 2014 at 11:45:34AM +0100, Jakob Truelsen wrote:
> Hi and thanks for the quick reply. Have remounted the filesystem with
> enospc_debug, and run the rebalance you suggested, with the trance
> below. So perhaps the next step is for me to figure out how to take a
> metadata image and s
Hi and thanks for the quick reply. Have remounted the filesystem with
enospc_debug, and run the rebalance you suggested, with the trance
below. So perhaps the next step is for me to figure out how to take a
metadata image and send it to josef (perhaps with a box of tissues)
/Jakob
[jakobt@soda ~
On 12/02/2014 09:51, Jakob Truelsen wrote:
Hello. I am experiencing "No space left on device" with a btrfs file
system, yet I cannot seem to find any exhausted resource. Could some
resource I do not know about be exhausted, or is this caused by
something else. Below is a trace of information that
On Wed, Feb 12, 2014 at 10:51:12AM +0100, Jakob Truelsen wrote:
> Hello. I am experiencing "No space left on device" with a btrfs file
> system, yet I cannot seem to find any exhausted resource. Could some
> resource I do not know about be exhausted, or is this caused by
> something else. Below is
Hello. I am experiencing "No space left on device" with a btrfs file
system, yet I cannot seem to find any exhausted resource. Could some
resource I do not know about be exhausted, or is this caused by
something else. Below is a trace of information that might be usefull,
please let me know if ther
29 matches
Mail list logo
