I'm really not to sure who to report this too, but my btrfs / partiton
segfaults when mounting. It also segfaults when trying to run btrfsck.
My setup:
Gentoo x64 install in Virtualbox (Windows 7 x64 host). 2.6.32_rc6
kernel. Recently converted from an ext4 filesystem with the
btrfs-convert utilit
On Wed, Nov 18, 2009 at 10:31:53PM +0100, Jan Engelhardt wrote:
> This left me puzzled for a while:
>
> 22:29 borg:/ # losetup /dev/loop1 /.B.disk
> 22:29 borg:/ # mount /dev/loop1 /B
> mount: /dev/loop1: can't read superblock
> 22:29 borg:/ # blkid /dev/loop1
> /dev/loop1: UUID="e19fe89b-cde3-4cc
Hi,
This left me puzzled for a while:
22:29 borg:/ # losetup /dev/loop1 /.B.disk
22:29 borg:/ # mount /dev/loop1 /B
mount: /dev/loop1: can't read superblock
22:29 borg:/ # blkid /dev/loop1
/dev/loop1: UUID="e19fe89b-cde3-4ccc-bc70-b759a57bd1c9"
UUID_SUB="f29c6218-d040-4546-a227-4dd2d2142817" TYP
Hello,
For some days, i've got oops on my system and i've investigate it a bit.
The trouble was with "posix_acl_equiv_mode" , and for some reason
(corrupted metadata ?) btrfs sometimes call it with "acl"==NULL
This function doesn't like it.
So in my patch I've first put a little error protection a
On Wed, Nov 18, 2009 at 10:20:29PM +0100, Jan Engelhardt wrote:
> Hi,
>
>
> the following testcase, if I remember the afternoon correctly, caused an
> oops on 2.6.31.6:
Oh, this was 2.6.31 ;) You'll want to pull from the btrfs unstable repo
or try 2.6.32-rc. In the oops below, you ran out of s
Hi,
the following testcase, if I remember the afternoon correctly, caused an
oops on 2.6.31.6:
>some.vol; # aka truncate -s 0
truncate -s $[10*1048576*1024] some.vol;
mkfs.btrfs some.vol;
mount some.vol /some.where -oloop;
truncate -s $[30*1048576*1024] some.vol;
btrfsctl -r 30G /some.where;
bt
> > Yeah df is just a fun ball of wax in many respects. We don't take into
> > account
> > RAID and we don't subtrace space thats strictly for metadata, so there are
> > several things that need to be fixed for df. Thanks,
> But as we have said many times... if we have different
> raid t
> > - Unless I'm missing something, there doesn't seem to be any way later
> >on to see that I set the data policy to raid1, except using
> >btrfs-dump-tree and checking the flags bits for the appropriate
> >group. Which can make things confusing if I have a bunch of btrfs
> >
"Yan, Zheng " writes:
> You can try mounting the FS in read only mode and copying files out.
> If you still get that error, try making verify_parent_transid() in disk-io.c
> always return 0. These are all we can do now.
Tried mounting it in read only mode, same problem:
[176994.933016] __ratel
