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 met
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 default
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 bi
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 group
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
---
mkfs.c | 21 +++-
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 doe
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) o
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 initramfs
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 subvol=r
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 subvol=
On 2013-11-14 22:22, Chris Murphy wrote:
>
> On Nov 14, 2013, at 1:47 PM, Goffredo Baroncelli 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 d
On Nov 14, 2013, at 1:47 PM, Goffredo Baroncelli 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 block group
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 Thu, Nov 14, 2013 at 07:54:21PM +, Leonidas Spyropoulos wrote:
> 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
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 physic
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 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 (inclu
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 ( which
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 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 fix them
> a
On Thu, Nov 14, 2013 at 11:37:39AM -0700, Chris Murphy wrote:
>
> On Nov 5, 2013, at 7:34 AM, Hugo Mills wrote:
>
> > On Tue, Nov 05, 2013 at 07:26:54AM -0700, Chris Murphy wrote:
> >>
> >> On Nov 5, 2013, at 5:16 AM, Russell Coker wrote:
> >>>
> >>> I presume that my filesystem is still corr
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.
On Nov 5, 2013, at 7:34 AM, Hugo Mills wrote:
> On Tue, Nov 05, 2013 at 07:26:54AM -0700, Chris Murphy wrote:
>>
>> On Nov 5, 2013, at 5:16 AM, Russell Coker wrote:
>>>
>>> I presume that my filesystem is still corrupt.
>>
>> I'm the original reporter of the bug. The file system itself isn't
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" r
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?
-chri
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 d
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.
>
>
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.
> > >
> >
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 sa
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 b
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 07:2
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
> > ---
> > mkfs.c | 6
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
---
mkfs.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/m
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
> ---
> mkfs.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/
>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 aga
Signed-off-by: David Sterba
---
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 filesystem
.PP
\fBbtrfs
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
---
mkfs.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/mkfs.c b/mkfs.c
index cd0af9ef8b4f..f825e1b6bc2d 100644
--- a
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 wrote:
> > >> For this to have any effect, 'h' must be added to getopt_long(), see
> > >> attached patch 1.
> > >>
> > >>
On Thu, Nov 14, 2013 at 11:25:55AM +0200, Ilya Dryomov wrote:
> On Wed, Nov 13, 2013 at 7:13 PM, David Sterba 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 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 no
Signed-off-by: Anand Jain
---
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 +366,7 @@ int btrfs_dev_
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
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 spl
On Wed, Nov 13, 2013 at 7:13 PM, David Sterba 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:
>>
>
43 matches
Mail list logo