Hi Liu,
(2014/06/24 16:39), Liu Bo wrote:
The reproducer is
$ mkfs.btrfs D1 D2 D3 -mraid5
$ mkfs.ext4 D2 mkfs.ext4 D3
$ mount D1 /btrfs -odegraded
Tested-by: Satoru Takeuchitakeuchi_sat...@jp.fujitsu.com
Here is the result of the last mount.
===
...
mount: wrong fs type, bad option, bad
Hi Satoru,
On Wed, Jun 25, 2014 at 04:25:01PM +0900, Satoru Takeuchi wrote:
Hi Liu,
(2014/06/24 16:39), Liu Bo wrote:
The reproducer is
$ mkfs.btrfs D1 D2 D3 -mraid5
$ mkfs.ext4 D2 mkfs.ext4 D3
$ mount D1 /btrfs -odegraded
Tested-by: Satoru
The reproducer is
$ mkfs.btrfs D1 D2 D3 -mraid5
$ mkfs.ext4 D2 mkfs.ext4 D3
$ mount D1 /btrfs -odegraded
---
[ 87.672992] [ cut here ]
[ 87.673845] kernel BUG at fs/btrfs/raid56.c:1828!
...
[ 87.673845] RIP: 0010:[813efc7e]
Hi!
I'm not sure whether this *should* be possible, but I think it *shouldn't*
crash:
I created a snapshot of the root directory within a subdirectory:
# mount /dev/sde2 /mnt
# cd /mnt
# mkdir save
# btrfs subvolume snapshot . save/snap1
# umount /mnt
Then I tried to mount the snapshot:
#
Michael Niederle wrote:
Hi!
I'm not sure whether this *should* be possible, but I think it *shouldn't*
crash:
I created a snapshot of the root directory within a subdirectory:
# mount /dev/sde2 /mnt
# cd /mnt
# mkdir save
# btrfs subvolume snapshot . save/snap1
# umount /mnt
Then
On Mon, Dec 6, 2010 at 7:40 PM, Li Zefan l...@cn.fujitsu.com wrote:
Michael Niederle wrote:
Hi!
I'm not sure whether this *should* be possible, but I think it *shouldn't*
crash:
It's currently not allowed to mount a subvolume which is not created in
the root directory of the default
We should drop dentry before deactivating the superblock, otherwise
we can hit this bug:
BUG: Dentry f349a690{i=100,n=/} still in use (1) [unmount of btrfs loop1]
...
Steps to reproduce the bug:
# mount /dev/loop1 /mnt
# mkdir save
# btrfs subvolume snapshot /mnt save/snap1
# umount
C Anthony Risinger wrote:
On Mon, Dec 6, 2010 at 7:51 PM, Li Zefan l...@cn.fujitsu.com wrote:
We should drop dentry before deactivating the superblock, otherwise
we can hit this bug:
BUG: Dentry f349a690{i=100,n=/} still in use (1) [unmount of btrfs loop1]
...
Steps to reproduce the bug:
On Sun, 2008-08-03 at 02:12 +0300, Ahmed Kamal wrote:
Hi guys,
I was playing on vmware with btrfs on complete disks /dev/sd{b,c,d,e}.
Next I decided to use partitions, so I created /dev/sd{b,c,d,e}1 and
used those, worked fine! Afterward, I mistakenly re-ran an old command
on the full disk (
Well, yeah sure. But I was kind of hoping my playing/testing is going
to help you guys fix it. So, does that traceback help you pin point
the problem ? If not, is there anything I can do, to help with that ?
I believe this crash should be re-producible .. haven't tested that
though
Regards
On
On Mon, 2008-08-04 at 15:59 +0300, Ahmed Kamal wrote:
Well, yeah sure. But I was kind of hoping my playing/testing is going
to help you guys fix it. So, does that traceback help you pin point
the problem ? If not, is there anything I can do, to help with that ?
I believe this crash should be
Hi guys,
I was playing on vmware with btrfs on complete disks /dev/sd{b,c,d,e}.
Next I decided to use partitions, so I created /dev/sd{b,c,d,e}1 and
used those, worked fine! Afterward, I mistakenly re-ran an old command
on the full disk ( mount -t btrfs -o subvol=. /dev/sdb /mnt/ ) notice
this is
12 matches
Mail list logo
