Hi Alex,
On 2014/03/28 0:50, Alex Lyakas wrote:
Hi Tsutomu Itoh,
On Thu, Mar 21, 2013 at 6:32 AM, Tsutomu Itoh wrote:
We should free leaf and root before returning from the error
handling code.
Signed-off-by: Tsutomu Itoh
---
fs/btrfs/disk-io.c | 12 +---
1 file changed, 9 insert
For modern filesystems such as btrfs, t/p/e size level operations
are common.
add size unit t/p/e parsing to memparse
Signed-off-by: Gui Hecheng
---
lib/cmdline.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/lib/cmdline.c b/lib/cmdline.c
index eb67
btrfs resize now support size unit parse of k/m/g/t/p/e in kernel space,
adopt the changes in userspace manpage.
Signed-off-by: Gui Hecheng
---
cmds-filesystem.c | 3 ++-
man/btrfs.8.in| 9 +
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/cmds-filesystem.c b/cmds-file
Originally following cmds will work:
# btrfs fi resize -10A
# btrfs fi resize -10Gaha
Filter the arg by checking the return pointer of memparse.
Signed-off-by: Gui Hecheng
---
fs/btrfs/ioctl.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/io
Steps to reproduce:
# mkfs.btrfs -f /dev/sda[8-11] -m raid5 -d raid5
# mount /dev/sda8 /mnt
# btrfs scrub start -BR /mnt
# echo $? <--unverified errors make return value be 3
This is because we don't setup right mapping between physical
and logical address for raid56, which makes checksum mism
On 31/03/14 12:03, Gui Hecheng wrote:
- * potentially suffixed with %K (for kilobytes, or 1024 bytes),
- * %M (for megabytes, or 1048576 bytes), or %G (for gigabytes, or
- * 1073741824). If the number is suffixed with K, M, or G, then
+ * potentially suffixed with
+ * %K (for
On 03/24/2014 05:58 AM, Wang Shilong wrote:
To compress a small write(<=blocksize) dosen't save us
disk space at all, skip it can save us some compression time.
This patch can also fix wrong setting nocompression flag for
inode, say a case when @total_in is 4096, and then we get
@total_compres
There's no point building the path string in each iteration of the
send_hole loop, as it produces always the same string.
Signed-off-by: Filipe David Borba Manana
---
fs/btrfs/send.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
in
2014-03-31 20:31 GMT+08:00 Chris Mason :
>
>
> On 03/24/2014 05:58 AM, Wang Shilong wrote:
>>
>> To compress a small write(<=blocksize) dosen't save us
>> disk space at all, skip it can save us some compression time.
>>
>> This patch can also fix wrong setting nocompression flag for
>> inode, say a
If we don't reschedule use rb_next to find the next extent state
instead of a full tree search, which is more efficient and safe
since we didn't release the io tree's lock.
Signed-off-by: Filipe David Borba Manana
---
fs/btrfs/extent_io.c |6 +-
1 file changed, 5 insertions(+), 1 deletio
2014-03-31 18:34 GMT+08:00 Wang Shilong :
> Steps to reproduce:
> # mkfs.btrfs -f /dev/sda[8-11] -m raid5 -d raid5
> # mount /dev/sda8 /mnt
> # btrfs scrub start -BR /mnt
> # echo $? <--unverified errors make return value be 3
>
> This is because we don't setup right mapping between physical
>
2014-03-31 20:54 GMT+08:00 Shilong Wang :
> 2014-03-31 18:34 GMT+08:00 Wang Shilong :
>> Steps to reproduce:
>> # mkfs.btrfs -f /dev/sda[8-11] -m raid5 -d raid5
>> # mount /dev/sda8 /mnt
>> # btrfs scrub start -BR /mnt
>> # echo $? <--unverified errors make return value be 3
>>
>> This is becau
In a normal scenario when sys-admin replaces a disk, the
expeted is btrfs will release the disk completely.
However the below test case gives a wrong impression that
replaced disk is still is in use.
$ btrfs rep start /dev/sde /dev/sdg4 /btrfs
$ mkfs.btrfs /dev/sde
/dev/sde appears to contain an
From: Anand Jain
This fix will ensure all SB copies on the disk is zeroed
when the disk is intentionally removed. This helps to
better manage disks in the user land.
Signed-off-by: Anand Jain
btrfs: don't double brelse on device rm
Device removal currently causes bdev removal to try to double
Hi, I probably should have used a better subject title. Also, I submitted this
without knowing if it would be helpful or not. If it can be used in a good way
Great! If not, then no problem. I appreciate you getting back with me, Marc.
Thanks. :)
On 03/30/2014 12:50 AM, Marc MERLIN wrote:
On
On Sat, Mar 29, 2014 at 05:21:23PM -0700, Marc MERLIN wrote:
> I had a look at
> http://bj0z.wordpress.com/2011/04/27/determining-snapshot-size-in-btrfs/#comment-35
> but it's quite old and does not work anymore since userland became
> incompatible with it.
>
> Has anyone seen something newer or h
Hi, I hadn't noticed this post,
I think I know the reason this time : you have used USB you bad guy!
I think USB does not support flush / barrier , which is mandatory for
BTRFS to work correctly in case of power loss.
For most filesystems actually, but the damages suffered by COW
filesystems suc
Firstly, it should be noted that I can mount and use my Btrfs file
system with nary an error or warning; however, I'm uncomfortable
using it while it's in some kind of inconsistent state.
The `btrfsck' tool is telling me the following:
Errors found in extent allocation tree or chunk allocation
Bob Marley posted on Mon, 31 Mar 2014 19:04:38 +0200 as excerpted:
> Hi, I hadn't noticed this post,
> I think I know the reason this time : you have used USB you bad guy!
> I think USB does not support flush / barrier , which is mandatory for
> BTRFS to work correctly in case of power loss.
> For
Michael Witten posted on Mon, 31 Mar 2014 17:39:05 + as excerpted:
> Firstly, it should be noted that I can mount and use my Btrfs file
> system with nary an error or warning; however, I'm uncomfortable using
> it while it's in some kind of inconsistent state.
>
> The `btrfsck' tool is tellin
On Mon, 31 Mar 2014 19:45:27 + (UTC), Duncan wrote:
> Hopefully, none of those commands included btrfsck --repair
... Woops...
Fortunately, it doesn't seem to have changed anything.
> That goes double if you're running raid5/6 mode
For the record, I've essentially just put Btrfs on 1 block
Michael Witten posted on Mon, 31 Mar 2014 20:33:39 + as excerpted:
> Just as an aside, I find it odd that the default for such a small system
> would be to duplicate user data.
I've wondered at that "logical accident" too, but the problem was that
data chunks default to a gig in size and met
Michael Witten posted on Mon, 31 Mar 2014 20:33:39 + as excerpted:
> I apologize if that ASCII art fails to render properly on your end.
FWIW I make a point of configuring monospace fonts as default for
internet message (Mail and news) bodies, precisely so I CAN properly view
ascii-art. So
On Mon, Mar 31, 2014 at 9:16 PM, Duncan wrote:
> FWIW I make a point of configuring monospace fonts as default for
> internet message (Mail and news) bodies, precisely so I CAN properly view
> ascii-art. So it came thru very nicely here. =:^)
That's good to know; unfortunately, you can never be
On Mon, 2014-03-31 at 13:17 +0200, Brendan Hide wrote:
> On 31/03/14 12:03, Gui Hecheng wrote:
> > - * potentially suffixed with %K (for kilobytes, or 1024 bytes),
> > - * %M (for megabytes, or 1048576 bytes), or %G (for gigabytes, or
> > - * 1073741824). If the number is suffixed with K, M, or G,
25 matches
Mail list logo
