On Wed, Nov 13, 2013 at 7:13 PM, David Sterba dste...@suse.cz wrote:
Hi,
On Sun, Jun 02, 2013 at 05:47:38PM +0200, Dieter Ries wrote:
For this to have any effect, 'h' must be added to getopt_long(), see
attached patch 1.
However, this results in btrfsck -h and --help doing different things:
Commit b02441999efcc6152b87cd58e7970bb7843f76cf Btrfs: don't wait for
the completion of all the ordered extents introduced a bug that broke
the ordered root list:
WARNING: CPU: 1 PID: 7119 at lib/list_debug.c:59 __list_del_entry+0x5a/0x98()
It is because we forgot to return the roots in the
Hi,
on a server that so far uses an MD RAID1 with XFS on it we wanted
to try btrfs, instead.
But even the most basic check for btrfs actually providing
resilience against one of the physical storage devices failing
yields a does not work result - so I wonder whether I misunderstood
that btrfs
Signed-off-by: Anand Jain anand.j...@oracle.com
---
fs/btrfs/dev-replace.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c
index 3e41097..97fcb73 100644
--- a/fs/btrfs/dev-replace.c
+++ b/fs/btrfs/dev-replace.c
@@ -366,7
On Fri, Nov 08, 2013 at 05:01:35PM -0500, Chris Mason wrote:
The patch below switches our default mkfs leafsize up to 16K. This
should be a better choice in almost every workload, but now is your
chance to complain if it causes trouble.
We should also turn the extended refs on by default now,
On Thu, Nov 14, 2013 at 11:25:55AM +0200, Ilya Dryomov wrote:
On Wed, Nov 13, 2013 at 7:13 PM, David Sterba dste...@suse.cz wrote:
For this to have any effect, 'h' must be added to getopt_long(), see
attached patch 1.
However, this results in btrfsck -h and --help doing different things:
On Thu, Nov 14, 2013 at 01:49:21PM +0100, David Sterba wrote:
On Thu, Nov 14, 2013 at 11:25:55AM +0200, Ilya Dryomov wrote:
On Wed, Nov 13, 2013 at 7:13 PM, David Sterba dste...@suse.cz wrote:
For this to have any effect, 'h' must be added to getopt_long(), see
attached patch 1.
A way of disabling features that are on by default in case it's not
wanted, eg. due to lack of support in the used kernel.
Signed-off-by: David Sterba dste...@suse.cz
---
mkfs.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mkfs.c b/mkfs.c
index
Signed-off-by: David Sterba dste...@suse.cz
---
man/btrfs.8.in | 14 ++
1 file changed, 14 insertions(+)
diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index 6cb3662e28bb..b6203483296e 100644
--- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -71,6 +71,8 @@ btrfs \- control a btrfs
Hello,
I wanted to make sure that my boot slowdown was related to space_cache so I
rebooted the PC several times and
it did become slower again. What is more, it doesn't seem like I even need to
generate any actual IO traffic
to trigger this.
I thought I might give clear_cache a shot again and
Quoting David Sterba (2013-11-14 08:30:45)
A way of disabling features that are on by default in case it's not
wanted, eg. due to lack of support in the used kernel.
Signed-off-by: David Sterba dste...@suse.cz
---
mkfs.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff
The feature has been introduced in kernel 3.7 and enabling it by
default is desired.
All features enabled by default are marked as such in
'mkfs.btrfs -O list-all' output.
Signed-off-by: David Sterba dste...@suse.cz
---
mkfs.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
On Thu, Nov 14, 2013 at 08:56:13AM -0500, Chris Mason wrote:
Quoting David Sterba (2013-11-14 08:30:45)
A way of disabling features that are on by default in case it's not
wanted, eg. due to lack of support in the used kernel.
Signed-off-by: David Sterba dste...@suse.cz
---
mkfs.c |
Hi,
I've found a few types of issues that appear throughout the patch,
commented the at the first occurance. It will be some work to fix them
all, but the transition to btrfs_wrr/... (and fixing the typos) is
desired and number of patches doing that should be minimal.
On Tue, Nov 12, 2013 at
The read only mount issue is by design. It is intended to make sure you
know exactly what is going on before you proceed. For example, a drive
may actually be fine, but may have been caused by a cable failure. In
that case you would want to fix the cable problem before you break the
mirror
Hi Linus,
Please pull my for-linus branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
This is our usual merge window set of bug fixes, performance
improvements and cleanups. Miao Xie has some really nice optimizations
for writeback.
Josef also expanded our
Quoting David Sterba (2013-11-14 09:14:14)
On Thu, Nov 14, 2013 at 08:56:13AM -0500, Chris Mason wrote:
Quoting David Sterba (2013-11-14 08:30:45)
A way of disabling features that are on by default in case it's not
wanted, eg. due to lack of support in the used kernel.
Quoting David Sterba (2013-11-14 07:41:21)
On Fri, Nov 08, 2013 at 05:01:35PM -0500, Chris Mason wrote:
The patch below switches our default mkfs leafsize up to 16K. This
should be a better choice in almost every workload, but now is your
chance to complain if it causes trouble.
We
On 11/14/2013 06:18 PM, George Mitchell wrote:
The read only mount issue is by design. It is intended to make sure you know
exactly what is going
on before you proceed.
Hmmm... but will a server be able to continue its operation (including writes)
on
an already mounted btrfs when a storage
Quoting David Sterba (2013-11-14 09:09:53)
The feature has been introduced in kernel 3.7 and enabling it by
default is desired.
All features enabled by default are marked as such in
'mkfs.btrfs -O list-all' output.
Has anyone already tested syslinux and grub with extrefs enabled?
-chris
--
On 2013-11-14 12:02, Lutz Vieweg wrote:
Hi,
on a server that so far uses an MD RAID1 with XFS on it we wanted
to try btrfs, instead.
But even the most basic check for btrfs actually providing
resilience against one of the physical storage devices failing
yields a does not work result -
On Nov 5, 2013, at 7:34 AM, Hugo Mills h...@carfax.org.uk wrote:
On Tue, Nov 05, 2013 at 07:26:54AM -0700, Chris Murphy wrote:
On Nov 5, 2013, at 5:16 AM, Russell Coker russ...@coker.com.au wrote:
I presume that my filesystem is still corrupt.
I'm the original reporter of the bug. The
On Thu, Nov 14, 2013 at 12:49:13PM -0500, Chris Mason wrote:
Quoting David Sterba (2013-11-14 09:09:53)
The feature has been introduced in kernel 3.7 and enabling it by
default is desired.
All features enabled by default are marked as such in
'mkfs.btrfs -O list-all' output.
Has
On Thu, Nov 14, 2013 at 11:37:39AM -0700, Chris Murphy wrote:
On Nov 5, 2013, at 7:34 AM, Hugo Mills h...@carfax.org.uk wrote:
On Tue, Nov 05, 2013 at 07:26:54AM -0700, Chris Murphy wrote:
On Nov 5, 2013, at 5:16 AM, Russell Coker russ...@coker.com.au wrote:
I presume that my
Hi,
Thanks for your comments, I've got a few comments/questions that I've
written below.
On Thu, Nov 14, 2013 at 10:25 AM, David Sterba dste...@suse.cz wrote:
Hi,
I've found a few types of issues that appear throughout the patch,
commented the at the first occurance. It will be some work to
Hello,
I've been following this list for years and I see during various situations
this message coming up. Some times it's a genuine problem that there is
actually not enough space. In other cases it's some by-product of something
else. I have seen this error personality on a broken system (
On 11/14/2013 11:35 AM, Lutz Vieweg wrote:
On 11/14/2013 06:18 PM, George Mitchell wrote:
The read only mount issue is by design. It is intended to make sure you
know exactly what is going
on before you proceed.
Hmmm... but will a server be able to continue its operation (including
Hello Sir / Mam,
We would like to have a chance to work on your website and get it positioned
top 10 on major search engines around the world ( Google Bing ). We are
presently working with 500+ clients world wide and we have made sure all our
clients rank top 10 for their best keywords. None
On 2013-11-14 19:22, Goffredo Baroncelli wrote:
On 2013-11-14 12:02, Lutz Vieweg wrote:
Hi,
on a server that so far uses an MD RAID1 with XFS on it we wanted
to try btrfs, instead.
But even the most basic check for btrfs actually providing
resilience against one of the physical storage
Hi Anand,
after some tests and looking at the code I discovered that the current
mkfs.btrfs doesn't allow any raid profile other than SINGLE for data and
meta-data when the mixed metadata/data group is enabled. It seems this
behaviour was introduce by a your commit [1].
mkfs.c line 1384 onwards
On Nov 14, 2013, at 1:47 PM, Goffredo Baroncelli kreij...@libero.it wrote:
Instead if I use the btrfs-progs c652e4efb8e2dd7... I got
[snip]
Data+Metadata: total=8.00MB, used=28.00KB
Note the absence of any RAID1 profile.
What happens if the devices are large enough to avoid mandatory
On 2013-11-14 22:22, Chris Murphy wrote:
On Nov 14, 2013, at 1:47 PM, Goffredo Baroncelli kreij...@libero.it wrote:
Instead if I use the btrfs-progs c652e4efb8e2dd7... I got
[snip]
Data+Metadata: total=8.00MB, used=28.00KB
Note the absence of any RAID1 profile.
What happens if the
On Fri, Nov 15, 2013 at 12:32:10AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
Hi,
I have a box with / and /home being subvolumes from the same btrfs filesystem.
/etc/fstab:
UUID=c0686... / btrfs subvol=root,x-systemd.device-timeout=0 1 1
UUID=c0686... /home btrfs
On Fri, Nov 15, 2013 at 12:43:51AM +0100, Karel Zak wrote:
On Fri, Nov 15, 2013 at 12:32:10AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
Hi,
I have a box with / and /home being subvolumes from the same btrfs
filesystem.
/etc/fstab:
UUID=c0686... / btrfs
Hi,
I have a box with / and /home being subvolumes from the same btrfs filesystem.
/etc/fstab:
UUID=c0686... / btrfs subvol=root,x-systemd.device-timeout=0 1 1
UUID=c0686... /home btrfs subvol=home,x-systemd.device-timeout=0 1 1
...
/ is initially mounted readonly by the
On 11/14/2013 09:35 AM, Lutz Vieweg wrote:
On 11/14/2013 06:18 PM, George Mitchell wrote:
The read only mount issue is by design. It is intended to make sure
you know exactly what is going
on before you proceed.
Hmmm... but will a server be able to continue its operation (including
writes)
Doing an if statement to test some condition to know if we should
trigger a tracepoint is pointless when tracing is disabled. This just
adds overhead and wastes a branch prediction. This is why the
TRACE_EVENT_CONDITION() was created. It places the check inside the jump
label so that the branch
This fixes the regression introduced with the patch
btrfs-progs: avoid write to the disk before sure to create fs
what happened with this patch is it missed the check to see if the
user has the option set before pushing the defaults.
Signed-off-by: Anand Jain anand.j...@oracle.com
---
Hi G.Baroncelli, Lutz,
Thanks for the test case and heads-up on this. The code missed
the check if the user has provided the option before default
profile for the mixed group (due to small vol) is enforced.
I have sent out the following patch to fix it.
[PATCH] btrfs-progs: for mixed
Goffredo Baroncelli posted on Thu, 14 Nov 2013 22:21:22 +0100 as
excerpted:
after some tests and looking at the code I discovered that the current
mkfs.btrfs doesn't allow any raid profile other than SINGLE for data and
meta-data when the mixed metadata/data group is enabled.
That'd be a big
Hi Anand,
On 2013-11-15 05:34, Anand Jain wrote:
This fixes the regression introduced with the patch
btrfs-progs: avoid write to the disk before sure to create fs
what happened with this patch is it missed the check to see if the
user has the option set before pushing the defaults.
On 2013-11-15 08:12, Duncan wrote:
Goffredo Baroncelli posted on Thu, 14 Nov 2013 22:21:22 +0100 as
excerpted:
after some tests and looking at the code I discovered that the current
mkfs.btrfs doesn't allow any raid profile other than SINGLE for data and
meta-data when the mixed
42 matches
Mail list logo
