On 07.07.2012 01:44, Sami Liedes wrote:
> [Retry: I think this mail didn't make it to the list, probably because
> of the 73 kilobyte attached log. Here's a URL to the file:]
>
>http://www.niksula.hut.fi/~sliedes/btrfs-scrub-debug.log.gz
>
> Sami
>
>
>
On 07/06/2012 02:45 PM, Alexander Block wrote:
> On Fri, Jul 6, 2012 at 2:03 PM, Goffredo Baroncelli
> wrote:
>> On 07/06/2012 01:55 PM, Chris Mason wrote:
>>> On Fri, Jul 06, 2012 at 02:51:43AM -0600, Alexander Block wrote:
On Fri, Jul 6, 2012 at 12:34 AM, Goffredo Baroncelli
wrote:
Allow better inspection of sizes using an environment variable.
Not pretty, but convenient to determine the exact size of a filesystem,
eg when resizing an underlying partition or LUN.
Pierre Carrier (2):
utils.c: fix sizes in B & malloc in pretty_sizes
utils.c: offer to limit divisions in pr
Before, sizes below 1KB where displayed in KB,
but without a unit.
Signed-off-by: Pierre Carrier
diff --git a/utils.c b/utils.c
index aade9e2..dde0513 100644
--- a/utils.c
+++ b/utils.c
@@ -1108,13 +1108,20 @@ char *pretty_sizes(u64 size)
size /= 1024;
num_divs++;
Dirty hack to allow inspection of sizes in lower units.
Useful to know the minimum size a partition shoud be resized to
after a 'btrfs filesystem resize'.
Label: 'home' uuid: 10453c4c-1c5b-4df5-b4a5-43a7f377430a
Total devices 1 FS bytes used 42.80GB
devid1 size 62.16GB used 6
I didn't test the initial patches enough.
A second round is coming.
This time it works fine:
devid1 size 66746609664.00 used 66746580992.00 path /dev/sda5
devid1 size 65182236.00KB used 65182208.00KB path /dev/sda5
devid1 size 63654.53MB used 63654.50MB path /dev/sda5
devid1 size 6
Before, sizes below 1KB are still displayed in KB,
but without a unit.
Signed-off-by: Pierre Carrier
diff --git a/utils.c b/utils.c
index aade9e2..937e763 100644
--- a/utils.c
+++ b/utils.c
@@ -1108,13 +1108,20 @@ char *pretty_sizes(u64 size)
size /= 1024;
num_div
Dirty hack to allow inspection of sizes in lower units.
Useful to know the minimum size a partition shoud be resized to
after a 'btrfs filesystem resize'.
Label: 'home' uuid: 10453c4c-1c5b-4df5-b4a5-43a7f377430a
Total devices 1 FS bytes used 42.80GB
devid1 size 62.16GB used 6
On Fri, Jul 06, 2012 at 07:37:42PM -0600, Shawn Landden wrote:
> From: Shawn Landen
>
> Fix creation of volumes using mkfs.btrfs on armv5.
[ use memcpy instead of direct structure accesses ]
Thanks for the patch. This should be a problem in the way gcc is run.
The kernel uses the same function
Hi Alexander,
I studied all the kernel + user code, and I have a long list of questions.
Meanwhile, I want to report two small bugs:
# BTRFS_SEND_C_MKNOD command: the receive path expects
BTRFS_SEND_A_MODE, but kernel doesn't send it. So currently it errors.
It looks like kernel need to send it,
On Fri, Jul 06, 2012 at 04:56:40PM +0200, Jan Schmidt wrote:
> Hi Mark,
>
> Sorry, I'm a bit late with my feedback.
No problem, thank you for taking the time to read these patches! Reply to
your most substantial comment is below. Everything else you pointed out I'll
have fixed up for an updated p
On openSUSE_12.1 with Btrfs v0.19+20120406, the following can be
observed: after a change of the profiles, total=,used= is no
longer shown:
20:49 mmsrv1:~ # btrfs fi df /top.srv/
Data, RAID10: total=152.00GiB, used=121.07GiB
System, RAID1: total=40.00MiB, used=44.00KiB
System: total=4.00MiB, use
On Mon, Jul 09, 2012 at 09:14:03PM +0200, Jan Engelhardt wrote:
>
> On openSUSE_12.1 with Btrfs v0.19+20120406, the following can be
> observed: after a change of the profiles, total=,used= is no
> longer shown:
>
>
> 20:49 mmsrv1:~ # btrfs fi df /top.srv/
> Data, RAID10: total=152.00GiB, used=1
On Monday 2012-07-09 21:25, Hugo Mills wrote:
>On Mon, Jul 09, 2012 at 09:14:03PM +0200, Jan Engelhardt wrote:
>>
>> On openSUSE_12.1 with Btrfs v0.19+20120406, the following can be
>> observed: after a change of the profiles, total=,used= is no
>> longer shown:
>>
>> 20:49 mmsrv1:~ # btrfs fi d
On Fri, Jul 06, 2012 at 04:57:29PM +0200, Jan Schmidt wrote:
> On Mon, May 21, 2012 at 23:46 (+0200), Mark Fasheh wrote:
> > From: Mark Fasheh
> >
> > The iterate_irefs in backref.c is used to build path components from inode
> > refs. This patch adds code to iterate extended refs as well.
> >
>
On Mon, Jul 09, 2012 at 10:06:24PM +0200, Jan Engelhardt wrote:
>
> On Monday 2012-07-09 21:25, Hugo Mills wrote:
> >On Mon, Jul 09, 2012 at 09:14:03PM +0200, Jan Engelhardt wrote:
> >>
> >> On openSUSE_12.1 with Btrfs v0.19+20120406, the following can be
> >> observed: after a change of the prof
> > diff --git a/fs/btrfs/inode-item.c b/fs/btrfs/inode-item.c
> > index baa74f3..496fb1c 100644
> > --- a/fs/btrfs/inode-item.c
> > +++ b/fs/btrfs/inode-item.c
> > @@ -18,6 +18,7 @@
> >
> > #include "ctree.h"
> > #include "disk-io.h"
> > +#include "hash.h"
> > #include "transaction.h"
> >
Error reporting is already done, so just return if root is NULL,
instead of segfaulting:
Program received signal SIGSEGV, Segmentation fault.
0x0042cd34 in create_metadump (input=0x7fffe847 "/usr/share",
out=0x63e010, num_threads=0, compress_level=0)
at btrfs-image.c:494
494
Anand Jain schrieb:>
>
>> What I have seen: buf is "0", after read_tree_block.
>
> Yes since we not checking extent_buffer_uptodate for the csum_root_tree,
> that will pass the null buf, The following patch will avoid sending null
> buffer
> https://patchwork.kernel.org/patch/1148831/
>
On Mon, Jul 09, 2012 at 10:06:24PM +0200, Jan Engelhardt wrote:
>
> On Monday 2012-07-09 21:25, Hugo Mills wrote:
> >On Mon, Jul 09, 2012 at 09:14:03PM +0200, Jan Engelhardt wrote:
> >>
> >> On openSUSE_12.1 with Btrfs v0.19+20120406, the following can be
> >> observed: after a change of the prof
Hi,
using btrfs with LVM snapshots seems to be confusing /proc/mounts
After mounting a snapshot of an original filesystem, the devicename of the
original filesystem is overwritten with that of the snapshot in /proc/mounts.
Steps to reproduce:
arnd@kallisto:/mnt$ sudo mount /dev/vg0/original /mnt
On Mon, Jul 9, 2012 at 4:22 PM, Arnd Hannemann wrote:
> Hi,
>
> using btrfs with LVM snapshots seems to be confusing /proc/mounts
> After mounting a snapshot of an original filesystem, the devicename of the
> original filesystem is overwritten with that of the snapshot in /proc/mounts.
If the lvm
Hi,
I have this problem after trying to run btrfsck.
I have new 11 HDDs WD 2tb, on two RAID controllers
Arch Linux, latest kernel. What I was doing was copying and reading
multiple data at the same time
After getting I/O errors while trying to access through samba and
while trying to run a VM with
Inodes always allocate free space with BTRFS_BLOCK_GROUP_DATA type,
which means every inode has the same BTRFS_I(inode)->free_space pointer.
This shrinks struct btrfs_inode by 4 bytes (or 8 bytes on 64 bits).
Signed-off-by: Li Zefan
---
fs/btrfs/btrfs_inode.h |3 ---
fs/btrfs/ctree.h
BTRFS_SETGET_FUNCS macro is used to generate btrfs_set_foo() and
btrfs_foo() functions, which read and write specific fields in the
extent buffer.
The total number of set/get functions is ~200, but in fact we only
need 8 functions: 2 for u8 field, 2 for u16, 2 for u32 and 2 for u64.
It results in
On Mon, Jul 09, 2012 at 11:05:47AM +0200, Arne Jansen wrote:
> > * Just before the crash:
> > btrfs: invalid parameters for read_extent_buffer: start (32771) > eb->len
> > (32768). eb start is 2261163409408, level 100, generation
> > 4412718571037421157, nritems 538968254. len param 17. debug
On 2012/7/5 9:52, Alexander Block wrote:
> On Thu, Jul 5, 2012 at 3:07 AM, Li Zefan wrote:
>> On 2012/7/4 19:04, Alexander Block wrote:
>>
>>> On Wed, Jul 4, 2012 at 9:56 AM, Li Zefan wrote:
On 2012/7/4 15:18, chandan r wrote:
> This patch adds a new member to the 'struct btrfs_ino
Thanks for doing this, I'll start looking into it right away.
One thing though: it's probably not the contents of struct eb
that's being corrupted, but the data the eb points to. See for
example read_extent_buffer to see how to access it. Sorry for
being unclear on this.
Thanks,
Arne
On 10.07.201
Christian,
line # is still confusing to me as well. patch was to avoid seg
fault when csum_root node is null and it might not be the case
here then.
(If the original problem stack-trace has remained the same
which is as below)..
-
(gdb) bt
#0 0x00402379 in btrfs_header_nri
On 10.07.2012 06:16, Sami Liedes wrote:
> On Mon, Jul 09, 2012 at 11:05:47AM +0200, Arne Jansen wrote:
>>> * Just before the crash:
>>> btrfs: invalid parameters for read_extent_buffer: start (32771) > eb->len
>>> (32768). eb start is 2261163409408, level 100, generation
>>> 4412718571037421157
The otime field is not zeroed, so users will see random otime in an old
filesystem with a new kernel which has otime support in the future.
The reserved bytes are also not zeroed, and we'll have compatibility
issue if we make use of those bytes.
Signed-off-by: Li Zefan
---
fs/btrfs/delayed-inod
31 matches
Mail list logo