Robert White posted on Wed, 17 Dec 2014 20:07:27 -0800 as excerpted:
> We have room for 1 more metadata extent on each
> drive, but if we allocate two more metadat extents on each drive we will
> burn up 1.25 GiB by reducing it to 0.75GiB.
FWIW, at least the last chunk assignment can be smaller
On Thu, 2014-12-18 at 16:39 +0900, Satoru Takeuchi wrote:
> From: Satoru Takeuchi
>
> When "/" is Btrfs, "btrfs property /" regards it
> as non-root by mistake.
>
> check_is_root() regards @object as a file system root if
> the following two conditions are satisfied.
>
> a) Both @object and i
On Wed, Dec 17, 2014 at 09:44:43PM -0800, Robert White wrote:
> On 12/16/2014 01:05 AM, Hugo Mills wrote:
> >On Mon, Dec 15, 2014 at 07:47:06PM -0800, Robert White wrote:
> >>I prefer "slice", not that I am totally happy with that word either.
> >>But by the time you get through loopback devices, m
Original Message
Subject: Re: [PATCH] btrfs: Enhance btrfs chunk allocation algorithm to
reduce ENOSPC caused by unbalanced data/metadata allocation.
From: Liu Bo
To: Qu Wenruo
Date: 2014年10月30日 17:39
On Thu, Oct 30, 2014 at 11:46:18AM +0800, Qu Wenruo wrote:
[snipped]
Ok
When btrfs allocate a chunk, it will try to alloc up to 1G for data and
256M for metadata, or 10% of all the writeable space if there is enough
space for the stripe on device.
However, when we run out of space, this allocation may cause unbalanced
chunk allocation.
For example, there are only 1G u
Hi,
On 17/12/14 17:49, David Sterba wrote:
> On Sat, Dec 13, 2014 at 03:35:09PM +0100, Merlijn Wajer wrote:
> [snip]
>
>> Attached are the two patches generated with git format-patch. I am aware
>> that this may not be required format for submitting patches -- but
>> please give me some time to g
On Wed, Dec 17, 2014 at 03:07:26PM +0100, David Sterba wrote:
> On Fri, Dec 12, 2014 at 01:35:14PM +0100, Karel Zak wrote:
> > This is first step to make btrfs-progs build system more conventional
> > for userspace users and developers. All is implemented by small incremental
> > patches to keep th
We're going to use -t for tera- units prefix, same as 'fi df' does.
Signed-off-by: David Sterba
---
cmds-fi-disk_usage.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/cmds-fi-disk_usage.c b/cmds-fi-disk_usage.c
index 6a33b5d1da51..77ab8b4c1604 100644
--- a/cmds-fi-dis
Copy from 'fi df' to 'fi usage' and 'dev usage'.
David Sterba (6):
btrfs-progs: fi usage, change option for tabular output to T
btrfs-progs: fi usage, add switches to set output units
btrfs-progs: fi usage, update manpage
btrfs-progs: dev usage, add switches to set output units
btrfs-pro
Signed-off-by: David Sterba
---
Documentation/btrfs-device.txt | 26 ++
1 file changed, 26 insertions(+)
diff --git a/Documentation/btrfs-device.txt b/Documentation/btrfs-device.txt
index 46c54b94413c..4cd633fe6c03 100644
--- a/Documentation/btrfs-device.txt
+++ b/Documen
Same set of options as 'fi df': binary and decimal bases, human readable
options etc.
Signed-off-by: David Sterba
---
cmds-fi-disk_usage.c | 64 +++-
1 file changed, 53 insertions(+), 11 deletions(-)
diff --git a/cmds-fi-disk_usage.c b/cmds-fi-dis
Use unsigned type and a common name everywhere.
Signed-off-by: David Sterba
---
cmds-device.c| 6 ++---
cmds-fi-disk_usage.c | 69 ++--
cmds-fi-disk_usage.h | 4 +--
3 files changed, 40 insertions(+), 39 deletions(-)
diff --git a/cmds-de
Same set of options as 'fi df': binary and decimal bases, human readable
options etc.
Signed-off-by: David Sterba
---
cmds-device.c | 60 +--
1 file changed, 50 insertions(+), 10 deletions(-)
diff --git a/cmds-device.c b/cmds-device.c
inde
Signed-off-by: David Sterba
---
Documentation/btrfs-filesystem.txt | 28
1 file changed, 28 insertions(+)
diff --git a/Documentation/btrfs-filesystem.txt
b/Documentation/btrfs-filesystem.txt
index a8f2972a0e1a..85a94eb52569 100644
--- a/Documentation/btrfs-filesyste
Hey,
I am hoping you guys can shed some light on my issue. I know that it's
a common question that people see differences in the "disk used" when
running different calculations, but I still think that my issue is
weird.
root@s4 / # mount
/dev/md3 on /opt/drives/ssd type btrfs
(rw,noatime,compress
Sorry, did not read the guidelines correctly. Here comes more info:
root@s4 /opt/drives/ssd # uname -a
Linux s4.podnix.com 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux
root@s4 /opt/drives/ssd # btrfs --version
Btrfs Btrfs v0.19
root@s4 /opt/drives/ssd # btrfs fi show
Label: none
On Thu, Dec 18, 2014 at 11:02:34PM +0800, Daniele Testa wrote:
> Sorry, did not read the guidelines correctly. Here comes more info:
>
> root@s4 /opt/drives/ssd # uname -a
> Linux s4.podnix.com 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64
> GNU/Linux
This is your problem. I think the di
On Mon, Dec 15, 2014 at 02:09:02PM +0800, Qu Wenruo wrote:
> It seems the second patch, which about 225K including a btrfs-image
> dump, can't pass the ml's size limit.
I've cherry-picked the commit with the test image.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
I am running latest Debian stable. However, I used backports to update
the kernel to 3.16.
root@s4 /opt/drives/ssd # uname -a
Linux s4.podnix.com 3.16.0-0.bpo.4-amd64 #1 SMP Debian
3.16.7-ckt2-1~bpo70+1 (2014-12-08) x86_64 GNU/Linux
root@s4 /opt/drives/ssd # btrfs --version
Btrfs v3.14.1
It stil
On Thu, Dec 18, 2014 at 11:29:40AM +0100, Merlijn Wajer wrote:
> That is fine; at this point there are not a lot of people using an
> alternative libc, so this is common practice. I'll be here with a new
> round of patches if it breaks in a future release; it shouldn't really
> break too often. :)
On 12/18/14 7:31 AM, Karel Zak wrote:
> On Wed, Dec 17, 2014 at 03:07:26PM +0100, David Sterba wrote:
>> On Fri, Dec 12, 2014 at 01:35:14PM +0100, Karel Zak wrote:
>>> This is first step to make btrfs-progs build system more conventional
>>> for userspace users and developers. All is implemented by
Hi guys,
The latest integration fails 'make test' with the following output:
[TEST]013-leaf-corruption-no-extent-data.tar.xz
btrfs check should have detected corruption
Makefile:144: recipe for target 'test' failed
make: *** [test] Error 1
rm btrfs-corrupt-block.o
I've only built the
On 18 December 2014 18:35:16 GMT+00:00, WorMzy Tykashi
wrote:
>Hi guys,
>
>The latest integration fails 'make test' with the following output:
>
> [TEST]013-leaf-corruption-no-extent-data.tar.xz
>btrfs check should have detected corruption
>Makefile:144: recipe for target 'test' failed
>
Hi,
Just to give you a really late feedback on this: I got it fixed with
btrfs-progs 3.17.3n on Linux 3.17.6, i.e. `btrfs rescue chunk-recover`
just did the job. Thanks for your advice.
-Kalle
Am 09/16/2014 um 03:46 AM schrieb Gui Hecheng:
> On Mon, 2014-09-15 at 16:59 +0200, Karl-Philipp Richter
Another way to defrag the file is to move the file to another disk and then
move it back. I've had trouble with virtual machine disks before (Windows
server raw) and this has fixed the problem.
FYI 3.17.2 and beyond seems much better now. No crazy slow downs.
Paul.
-Original Message-
F
The other thing going on here is that every write is going to be COW,
which isn't ideal for VM images. Another thing that I wonder is what
SSD this is and if it's supporting deterministic TRIM, since discard
is enabled. And I'm not sure that md by default is passing down trim
(?). This is on md rai
On Thu, Dec 18, 2014 at 6:57 PM, Chris Murphy wrote:
> The other thing going on here is that every write is going to be COW,
> which isn't ideal for VM images.
Reminder goes here for setting xattr +C on VM images. You can't set it
after the fact though. Only at the time the file is created. A ref
On Sun, Dec 14, 2014 at 10:06:50PM -0800, Robert White wrote:
> ABSTRACT:: Stop being clever, just give the raw values. That's what
> you should be doing anyway. There are no other correct values to
> give that doesn't blow someone's paradigm somewhere.
The trouble is a lot of existing software ca
Hi David,
On 2014/12/18 23:27, David Sterba wrote:
> Signed-off-by: David Sterba
> ---
> Documentation/btrfs-filesystem.txt | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/Documentation/btrfs-filesystem.txt
> b/Documentation/btrfs-filesystem.txt
> index
From: Satoru Takeuchi
---
Tested with dev/integration-20141218 + this patch
---
cmds-fi-disk_usage.c | 8
cmds-filesystem.c| 8
utils.h | 3 +++
3 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/cmds-fi-disk_usage.c b/cmds-fi-disk_usage.c
index
Cleanup warning when compile btrfs-progs with clang.
Clang analyser also reports about 60+ errors, but it will be another
patchset fixing it later.
Qu Wenruo (5):
btrfs-progs: Makefile: Move linker only option to LDFLAGS
btrfs-progs: Fix a clang dead-judgement warning in disk-io.c.
btrfs-pr
Fix the following clang warning:
free-space-cache.c:464:19: warning: unused function 'offset_to_bitmap'
[-Wunused-function]
static inline u64 offset_to_bitmap(struct btrfs_free_space_ctl *ctl,
^
1 warning generated.
Signed-off-by: Qu Wenruo
---
free-space-cache.c | 16
Fix the following gcc(>4.9) and clang warning:
In file included from cmds-receive.c:24:
In file included from ./kerncompat.h:22:
In file included from /usr/include/stdio.h:27:
/usr/include/features.h:148:3: warning: "_BSD_SOURCE and _SVID_SOURCE
are deprecated, use _DEFAULT_SOURCE" [-W#warnings]
Move the linker only option -rdynamic to LDFLAGS.
This resolve lots of the following warning if using clang as CC:
clang: warning: argument unused during compilation: '-rdynamic'
Signed-off-by: Qu Wenruo
---
Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile
When compiled with clang, the following warning is outputted.
disk-io.c:1017:15: warning: comparison of unsigned expression < 0 is
always false [-Wtautological-compare]
if (dev_size < 0)
^ ~
1 warning generated.
This is because dev_size is defined as unsigned type, bu
Fix the following clang warning when compiling btrfs-progs:
radix-tree.c:78:21: warning: unused function 'root_gfp_mask'
[-Wunused-function]
static inline gfp_t root_gfp_mask(struct radix_tree_root *root)
^
1 warning generated.
Signed-off-by: Qu Wenruo
---
radix-tree.c | 5 -
Original Message
Subject: Re: btrfs-progs: integration-20141218 possible corruption test
regression
From: WorMzy Tykashi
To:
Date: 2014年12月19日 02:39
On 18 December 2014 18:35:16 GMT+00:00, WorMzy Tykashi
wrote:
Hi guys,
The latest integration fails 'make test'
From: Satoru Takeuchi
Enhance the document of btrfs property as follows.
- Add the description about the candidates of .
- Enrich the description of .
- Fix typos and some redundancy.
Signed-off-by: Satoru Takeuchi
Reported-by: Naohiro Aota
---
Documentation/btrfs-property.txt | 32
38 matches
Mail list logo