On 10/23/2012 01:05 AM, Jan Schmidt wrote:
> Hi liubo,
>
> On Mon, October 22, 2012 at 16:02 (+0200), Liu Bo wrote:
>> According to btree's balance algorithm, when we split a root into two parts,
>> we insert a new one to be their parent:
>>
>> new
On Oct 22, 2012, at 1:50 PM, Hugo Mills wrote:
>
> Yes, the automatic single -> RAID-0 upgrade was fixed. If you
> haven't run a balance on (at least) the metadata after adding the new
> device, then you won't get the DUP -> RAID-1 upgrade on metadata. (I
> can tell you haven't run the balance
On 2012-10-22 21:50, Hugo Mills wrote:
> It's more like a balance which moves everything that has
> some (part of its) existence on a device. So when you have
> RAID-0 or RAID-1 data, all of the related chunks on other
> disks get moved too (so in RAID-1, it's the mirror chunk as
>>
Arne Jansen gmx.net> writes:
>
> There are some unaligned accesses in progs that cause malfunction or
> crashes on ARM.
> This patch fixes the ones we stumbled upon.
>
> Signed-off-by: Arne Jansen gmx.net>
> ---
>
> Change v1->v2:
> Somehow sent the wrong patch without the patch to the setget
From: Goffredo Baroncelli
Check that the suffix for the parse_size() input is of only
one character.
---
utils.c | 12
1 file changed, 12 insertions(+)
diff --git a/utils.c b/utils.c
index 732c782..de75309 100644
--- a/utils.c
+++ b/utils.c
@@ -1226,6 +1226,11 @@ u64 parse_size(c
From: Goffredo Baroncelli
Replace the function atoll with strtoull()
---
utils.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/utils.c b/utils.c
index 705be7b..732c782 100644
--- a/utils.c
+++ b/utils.c
@@ -1243,6 +1243,6 @@ u64 parse_size(char *s)
}
From: Goffredo Baroncelli
---
man/btrfs.8.in |3 +++
man/mkfs.btrfs.8.in |3 +++
2 files changed, 6 insertions(+)
diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index 9222580..33bd78d 100644
--- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -184,6 +184,9 @@ defragment operations.
\fB-t
From: Goffredo Baroncelli
Add new suffixes in parse_size() function. New suffixes are: T as
terabyte, P as petabyte, E as exabyte. Note these units are
multiply of 2 .
---
utils.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/utils.c b/utils.c
index de75309..a5fabdc 100644
--- a/u
From: Goffredo Baroncelli
Move the function from cmds-filesystem.c and mkfs.c to utils.c
---
cmds-filesystem.c | 26 --
mkfs.c| 31 ---
utils.c | 26 ++
utils.h |2 ++
4 files ch
Hi all,
the following patches attempt to address some issues to the function
parse_size():
- this function is defined both in mkfs.c and cmds-filesystem.c; I
moved it in utils.c (which is already used in both mkfs.btrfs and
btrfs) in order to avoid code duplication.
- it used the function atoll()
On Mon, Oct 22, 2012 at 10:14:58AM -0600, Alex Elder wrote:
> On 10/19/2012 04:01 PM, Josef Bacik wrote:
> > Alex reported a problem where we were writing between chunks on a rbd
> > device. The thing is we do bio_add_page using logical offsets, but the
> > physical offset may be different. So wh
On Fri, Oct 19, 2012 at 08:31:17PM -0600, Liu Bo wrote:
> On 10/20/2012 05:01 AM, Josef Bacik wrote:
> > Alex reported a problem where we were writing between chunks on a rbd
> > device. The thing is we do bio_add_page using logical offsets, but the
> > physical offset may be different. So when w
Dave gave me an image of a very full file system that would abort the
transaction because it ran out of space while committing the transaction.
This is because we would think there was plenty of room to create a snapshot
even though the global reserve was not full. This happens because we
calculat
On Mon, Oct 22, 2012 at 01:36:31PM -0600, Chris Murphy wrote:
> On Oct 22, 2012, at 11:18 AM, Hugo Mills wrote:
> >
> > It's more like a balance which moves everything that has some (part
> > of its) existence on a device. So when you have RAID-0 or RAID-1 data,
> > all of the related chunks on
We BUG if we fail to commit the transaction when creating a snapshot, which
is just obnoxious. Remove the BUG_ON(). Thanks,
Signed-off-by: Josef Bacik
---
fs/btrfs/ioctl.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 3b8b5
On a really full file system I was getting ENOSPC back from
btrfs_update_inode when trying to update the parent inode when creating a
snapshot. Just use the fallback method so we can update the inode and not
have to worry about having a delayed ref. Thanks,
Signed-off-by: Josef Bacik
---
fs/bt
On Oct 22, 2012, at 11:04 AM, Goffredo Baroncelli wrote:
> Which version of "btrfs" tool are you using ? There was a bug on this.
> Try the latest.
No idea.
On Oct 22, 2012, at 11:18 AM, Hugo Mills wrote:
>
> It's more like a balance which moves everything that has some (part
> of its) exi
On 10/22/2012 06:05 PM, Hugo Mills wrote:
> On Mon, Oct 22, 2012 at 10:58:07AM -0500, Michael wrote:
>> Does anyone know when RAID 5/6 are planned to be included in the
>> Kernel?
>
> This is in the FAQ:
>
>
https://btrfs.wiki.kernel.org/index.php/FAQ#Can_I_use_RAID.5B56.5D_on_my_Btrfs_filesystem.
On Mon, Oct 22, 2012 at 10:42:18AM -0600, Chris Murphy wrote:
> Thanks for the response Hugo,
>
> On Oct 22, 2012, at 3:19 AM, Hugo Mills wrote:
>
> > I'm not entirely sure what's going on here(*), but it looks like an
> > awkward interaction between the unequal sizes of the devices, the fact
Hi liubo,
On Mon, October 22, 2012 at 16:02 (+0200), Liu Bo wrote:
> According to btree's balance algorithm, when we split a root into two parts,
> we insert a new one to be their parent:
>
> new root
> node A
On 2012-10-22 18:42, Chris Murphy wrote:
> [root@f18v ~]# btrfs fi show
> failed to read /dev/sr0
> Label: none uuid: 6e96a96e-3357-4f23-b064-0f0713366d45
> Total devices 5 FS bytes used 7.52GB
> devid5 size 12.00GB used 4.17GB path /dev/sdf
> devid4 size 12.00GB used 4.6
On 2012-10-22 13:38, Miao Xie wrote:
> Step to reproduce:
> # mkfs.btrfs
> # mount -o user_subvol_rm_allowed
> # mkdir /dir0
> # chmod 777 /dir0
> # btrfs sub snap /dir0/snap0
> # su -c "btrfs sub del /dir0/snap0" -s /bin/bash nobody
> ERROR: cannot delete '/dir0/snap0' - Permission deni
Thanks for the response Hugo,
On Oct 22, 2012, at 3:19 AM, Hugo Mills wrote:
> I'm not entirely sure what's going on here(*), but it looks like an
> awkward interaction between the unequal sizes of the devices, the fact
> that three of them are very small, and the RAID-0/RAID-1 on
> data/meta
On Mon, Oct 22, 2012 at 12:41:49AM -0600, Arne Jansen wrote:
> On 15.10.2012 16:32, Chris Mason wrote:
> > On Sat, Oct 13, 2012 at 09:41:28AM -0600, David Sterba wrote:
> >> On Sat, Oct 13, 2012 at 09:08:57AM +0100, Rory Campbell-Lange wrote:
> >>> Perhaps "BTRFS Incremental Stream" or "Backup Incr
On 10/19/2012 04:01 PM, Josef Bacik wrote:
> Alex reported a problem where we were writing between chunks on a rbd
> device. The thing is we do bio_add_page using logical offsets, but the
> physical offset may be different. So when we map the bio now check to see
> if the bio is still ok with the
On 10/19/2012 09:31 PM, Liu Bo wrote:
>> +
>> > + prev = &bio->bi_io_vec[bio->bi_vcnt - 1];
> I prefer 'last' for this.
I said exactly the same thing.
> Others look good to me :)
>
> Reviewed-by: Liu Bo
-Alex
--
To unsubscribe from this list: send the l
On Mon, Oct 22, 2012 at 10:58:07AM -0500, Michael wrote:
> Does anyone know when RAID 5/6 are planned to be included in the
> Kernel?
This is in the FAQ:
https://btrfs.wiki.kernel.org/index.php/FAQ#Can_I_use_RAID.5B56.5D_on_my_Btrfs_filesystem.3F
Short answer: Not yet, probably soon.
> I
Hello,
Does anyone know when RAID 5/6 are planned to be included in the
Kernel? I am starting to buy parts for my next computer and would very
much like to use BTRFS because I want a FS that can grow and also
recover from undetected read errors - it will be large enough that
these are possible. I'm
Here is an excerpt of btrfsck:
# ./btrfsck /dev/nbd1
checking extents
corrupt extent record: key 314454016 168 524288
corrupt extent record: key 314978304 168 524288
corrupt extent record: key 315502592 168 524288
corrupt extent record: key 316026880 168 524288
corrupt extent record: key 316551168
Tried with cmason 3.6.0 for-linus tree. Did a "find" on the BTRFS.
[ 152.846595] [ cut here ]
[ 152.848841] kernel BUG at fs/btrfs/extent-tree.c:1519!
[ 152.848841] invalid opcode: [#1] SMP
[ 152.848841] Modules linked in:
[ 152.848841] CPU 0
[ 152.848841] Pid: 1
btrfs can use generic_file_read_iter(). Base btrfs_file_write_iter()
on btrfs_file_aio_write(), then have the latter call the former.
Signed-off-by: Dave Kleikamp
Cc: Zach Brown
Cc: Chris Mason
Cc: linux-btrfs@vger.kernel.org
---
fs/btrfs/file.c | 55 ++-
According to btree's balance algorithm, when we split a root into two parts,
we insert a new one to be their parent:
new root
node A/ \
| x1 x2 x3 x4 x5 x6 | => node A
On 10/19/2012 10:37 AM, Rory Campbell-Lange wrote:
> From my perspective as a user I would be grateful if the following changes in
> syntax for listing subvolumes could be considered:
>
> In addition to
>
> btrfs subvolume list [-apurts] [-g [+|-]value] [-c [+|-]value]
> [--sort=gen,ogen,r
On Mon, Oct 22, 2012 at 5:39 AM, Miao Xie wrote:
> Step to reproduce:
> # mkfs.btrfs
> # mount
> # btrfs sub create /subv0
> # btrfs sub snap /subv0/snap0
> # change /subv0 from R/W to R/O
> # btrfs sub del /subv0/snap0
>
> We deleted the snapshot successfully. I think we should not be a
Step to reproduce:
# mkfs.btrfs
# mount
# btrfs sub create /subv0
# btrfs sub snap /subv0/snap0
# change /subv0 from R/W to R/O
# btrfs sub del /subv0/snap0
We deleted the snapshot successfully. I think we should not be able to delete
the snapshot since the parent subvolume is R/O.
Sign
Step to reproduce:
# mkfs.btrfs
# mount -o user_subvol_rm_allowed
# mkdir /dir0
# chmod 777 /dir0
# btrfs sub snap /dir0/snap0
# su -c "btrfs sub del /dir0/snap0" -s /bin/bash nobody
ERROR: cannot delete '/dir0/snap0' - Permission denied
This is because we checked the permission of the
On Mon, Oct 22, 2012 at 12:02:08AM -0600, Chris Murphy wrote:
>
> On Oct 21, 2012, at 10:32 PM, Chris Murphy wrote:
>
> > This is stock Fedora 18 beta kernel, 3.6.1-1.fc18.x86_64 #1 SMP Mon Oct 8
> > 17:19:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
>
> Probably not a good idea to omit this is
hi,
I have a 2 drive btrfs raid set up. It was created first with a single drive,
and then adding a second and doing
btrfs fi balance start -dconvert=raid1 /data
the original drive is showing smart errors so i want to replace it. i dont
easily have space in my desktop for an extra disk, so i de
38 matches
Mail list logo
