bug: missing snapshot as in the btrfs subvolume list command

2011-07-05 Thread Anand Jain



A confirmation if the following bug is being taken care will help.

Have 9 sub-vols `btrfs subvolume list /btrfs`
-
# btrfs subvolume list /btrfs
ID 256 top level 5 path sv1
ID 257 top level 5 path snapy23988
ID 258 top level 5 path snapi24000
ID 259 top level 5 path snapC24009
ID 260 top level 5 path snapo24018
ID 261 top level 5 path snapm24027
ID 262 top level 5 path snapx24036
ID 263 top level 5 path snape24045
ID 264 top level 5 path snapt24054
# btrfs subvolume list /btrfs | wc -l
9


and create 10th subvol
---
# S=`mktemp -u /btrfs/snapXX`; btrfs subvolume snapshot 
/btrfs/snapt24054 $S

Create a snapshot of '/btrfs/snapt24054' in '/btrfs/snapm24071'
--

now list fails to report ID 261 (note that last snapshot was
successfully created)

# btrfs subvolume list /btrfs
ID 256 top level 5 path sv1
ID 257 top level 5 path snapy23988
ID 258 top level 5 path snapi24000
ID 259 top level 5 path snapC24009
ID 260 top level 5 path snapo24018
ID 262 top level 5 path snapx24036
ID 263 top level 5 path snape24045
ID 264 top level 5 path snapt24054
ID 265 top level 5 path snapm24071
# btrfs subvolume list /btrfs | wc -l
9
#
--

only happens at 10th subvol if you create 11th subvol list if fine.
--
# S=`mktemp -u /btrfs/snapXX`; btrfs subvolume snapshot 
/btrfs/snapm24071 $S

Create a snapshot of '/btrfs/snapm24071' in '/btrfs/snapR24080'
# btrfs subvolume list /btrfs
ID 256 top level 5 path sv1
ID 257 top level 5 path snapy23988
ID 258 top level 5 path snapi24000
ID 259 top level 5 path snapC24009
ID 260 top level 5 path snapo24018
ID 261 top level 5 path snapm24027
ID 262 top level 5 path snapx24036
ID 263 top level 5 path snape24045
ID 264 top level 5 path snapt24054
ID 265 top level 5 path snapm24071
ID 266 top level 5 path snapR24080
# btrfs subvolume list /btrfs | wc -l
11
#
---

Thanks,
-Anand
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: bug: missing snapshot as in the btrfs subvolume list command

2011-07-05 Thread Hugo Mills
On Tue, Jul 05, 2011 at 06:10:42PM +0800, Anand Jain wrote:
 A confirmation if the following bug is being taken care will help.
 
 Have 9 sub-vols `btrfs subvolume list /btrfs`
 -
 # btrfs subvolume list /btrfs
 ID 256 top level 5 path sv1
 ID 257 top level 5 path snapy23988
 ID 258 top level 5 path snapi24000
 ID 259 top level 5 path snapC24009
 ID 260 top level 5 path snapo24018
 ID 261 top level 5 path snapm24027
 ID 262 top level 5 path snapx24036
 ID 263 top level 5 path snape24045
 ID 264 top level 5 path snapt24054
 # btrfs subvolume list /btrfs | wc -l
 9
 
 
 and create 10th subvol
 ---
 # S=`mktemp -u /btrfs/snapXX`; btrfs subvolume snapshot
 /btrfs/snapt24054 $S
 Create a snapshot of '/btrfs/snapt24054' in '/btrfs/snapm24071'
 --
 
 now list fails to report ID 261 (note that last snapshot was
 successfully created)
 
 # btrfs subvolume list /btrfs
 ID 256 top level 5 path sv1
 ID 257 top level 5 path snapy23988
 ID 258 top level 5 path snapi24000
 ID 259 top level 5 path snapC24009
 ID 260 top level 5 path snapo24018
 ID 262 top level 5 path snapx24036
 ID 263 top level 5 path snape24045
 ID 264 top level 5 path snapt24054
 ID 265 top level 5 path snapm24071
 # btrfs subvolume list /btrfs | wc -l
 9
 #
 --

   Could you try this with the integration branch of the btrfs tools,
available from:

http://git.darksatanic.net/repo/btrfs-progs-unstable.git/

in the integration-20110703 branch. There's a patch in there that
should deal with this particular problem (if it's what I think it is,
which it probably is).

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
 --- Once is happenstance; twice is coincidence; three times --- 
is enemy action. 


signature.asc
Description: Digital signature


[GIT PULL] scrub updates for 3.1

2011-07-05 Thread Arne Jansen
Hi Chris,

since rc-6 seems to be the last rc for 3.0 and in case you're already
preparing your pull request for 3.1, can you please pull the following
updates for scrub, based on your for-linus tree (2f7e33d432)?

git://git.kernel.org/pub/scm/linux/kernel/git/arne/btrfs-unstable-arne.git
for-chris

It just contains the readahead patch, which gives a significant
performance improvement for scrub. Currently scrub is the only
consumer.

Thanks,
Arne

Arne Jansen (7):
  btrfs: add an extra wait mode to read_extent_buffer_pages
  btrfs: add READAHEAD extent buffer flag
  btrfs: state information for readahead
  btrfs: initial readahead code and prototypes
  btrfs: hooks for readahead
  btrfs: test ioctl for readahead
  btrfs: use readahead API for scrub

 fs/btrfs/Makefile|3 +-
 fs/btrfs/ctree.h |   21 ++
 fs/btrfs/disk-io.c   |   85 +-
 fs/btrfs/disk-io.h   |2 +
 fs/btrfs/extent_io.c |9 +-
 fs/btrfs/extent_io.h |4 +
 fs/btrfs/ioctl.c |   93 +-
 fs/btrfs/ioctl.h |   16 +
 fs/btrfs/reada.c |  949
++
 fs/btrfs/scrub.c |  116 +++
 fs/btrfs/volumes.c   |8 +
 fs/btrfs/volumes.h   |8 +
 12 files changed, 1239 insertions(+), 75 deletions(-)
 create mode 100644 fs/btrfs/reada.c
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[BUG] delayed inodes and reflinks

2011-07-05 Thread Jan Schmidt
Hi,

I hit this bug an hour ago while executing some cp --reflink:

Jul  5 13:54:02 oglaroon kernel: [ 2654.545244] [ cut here
]
Jul  5 13:54:02 oglaroon kernel: [ 2654.600508] kernel BUG at
fs/btrfs/delayed-inode.c:1637!
Jul  5 13:54:02 oglaroon kernel: [ 2654.664052] invalid opcode: 
[#1] SMP
Jul  5 13:54:02 oglaroon kernel: [ 2654.713244] last sysfs file:
/sys/devices/pci:00/:00:1c.4/:04:00.0/net/eth3/broadcast
Jul  5 13:54:02 oglaroon kernel: [ 2654.819429] CPU 1
Jul  5 13:54:02 oglaroon kernel: [ 2654.841372] Modules linked in: btrfs
mpt2sas scsi_transport_sas raid_class [last unloaded: btrfs]
Jul  5 13:54:02 oglaroon kernel: [ 2654.950364]
Jul  5 13:54:02 oglaroon kernel: [ 2654.968147] Pid: 22343, comm: cp
Tainted: GW   2.6.39+ #2 Supermicro X8SIL/X8SIL
Jul  5 13:54:02 oglaroon kernel: [ 2655.065386] RIP:
0010:[a0222490]  [a0222490]
btrfs_delayed_update_inode+0x120/0x130 [btrfs]
Jul  5 13:54:02 oglaroon kernel: [ 2655.186237] RSP:
0018:88023010dbd8  EFLAGS: 00010286
Jul  5 13:54:02 oglaroon kernel: [ 2655.249780] RAX: ffe4
RBX: 8802356bec40 RCX: 00018000
Jul  5 13:54:02 oglaroon kernel: [ 2655.335164] RDX: 0047
RSI:  RDI: 880230a84390
Jul  5 13:54:02 oglaroon kernel: [ 2655.420652] RBP: 88023010dc18
R08: 825eb2a0 R09: 0001
Jul  5 13:54:02 oglaroon kernel: [ 2655.506036] R10: 03e0
R11: 8802317c4560 R12: 8802356bec88
Jul  5 13:54:02 oglaroon kernel: [ 2655.591419] R13: 88023569c6f8
R14: 88023334f000 R15: 880234318000
Jul  5 13:54:02 oglaroon kernel: [ 2655.676803] FS:
7f07d396c700() GS:88023fc4() knlGS:
Jul  5 13:54:02 oglaroon kernel: [ 2655.773733] CS:  0010 DS:  ES:
 CR0: 80050033
Jul  5 13:54:02 oglaroon kernel: [ 2655.842476] CR2: 00407407
CR3: 000230974000 CR4: 06e0
Jul  5 13:54:02 oglaroon kernel: [ 2655.927859] DR0: 
DR1:  DR2: 
Jul  5 13:54:02 oglaroon kernel: [ 2656.013245] DR3: 
DR6: 0ff0 DR7: 0400
Jul  5 13:54:02 oglaroon kernel: [ 2656.098733] Process cp (pid: 22343,
threadinfo 88023010c000, task 8802317c3e80)
Jul  5 13:54:02 oglaroon kernel: [ 2656.194516] Stack:
Jul  5 13:54:02 oglaroon kernel: [ 2656.218540]  88023010dc38
00018000 013b 88023569c6f8
Jul  5 13:54:02 oglaroon kernel: [ 2656.307564]  88023334f000
88023569c6f8 88023568d000 
Jul  5 13:54:02 oglaroon kernel: [ 2656.396483]  88023010dc68
a01db4de 0068 
Jul  5 13:54:02 oglaroon kernel: [ 2656.485403] Call Trace:
Jul  5 13:54:02 oglaroon kernel: [ 2656.514742]  [a01db4de]
btrfs_update_inode+0x3e/0x150 [btrfs]
Jul  5 13:54:02 oglaroon kernel: [ 2656.593884]  [a0209160]
btrfs_ioctl_clone+0x9e0/0xca0 [btrfs]
Jul  5 13:54:02 oglaroon kernel: [ 2656.673022]  [81151f00] ?
might_fault+0x40/0xa0
Jul  5 13:54:02 oglaroon kernel: [ 2656.737613]  [a0209b05]
btrfs_ioctl+0x335/0xf70 [btrfs]
Jul  5 13:54:02 oglaroon kernel: [ 2656.810612]  [81151f57] ?
might_fault+0x97/0xa0
Jul  5 13:54:02 oglaroon kernel: [ 2656.875198]  [81151f0e] ?
might_fault+0x4e/0xa0
Jul  5 13:54:02 oglaroon kernel: [ 2656.939782]  [81859006] ?
_raw_spin_unlock+0x26/0x30
Jul  5 13:54:02 oglaroon kernel: [ 2657.009567]  [8117fcd3] ?
cp_new_stat+0xf3/0x110
Jul  5 13:54:02 oglaroon kernel: [ 2657.075325]  [8118cb5c]
do_vfs_ioctl+0x9c/0x560
Jul  5 13:54:02 oglaroon kernel: [ 2657.139982]  [818607ac] ?
sysret_check+0x27/0x62
Jul  5 13:54:02 oglaroon kernel: [ 2657.205604]  [8118d0b9]
sys_ioctl+0x99/0xa0
Jul  5 13:54:02 oglaroon kernel: [ 2657.266133]  [8186077b]
system_call_fastpath+0x16/0x1b
Jul  5 13:54:02 oglaroon kernel: [ 2657.337995] Code: f8 05 00 00 8d 0c
49 48 89 ca 48 89 4d c8 e8 c8 c7 f9 ff 85 c0 48 8b 4d c8 75 10 48 89 4b
08 e9 3d ff ff ff 0f 1f 80 00 00 00 00 0f 0b eb fe 66 66 66 2e 0f 1f
84 00 00 00 00 00 55 48 89 e5 41
Jul  5 13:54:02 oglaroon kernel: [ 2657.570642] RIP
[a0222490] btrfs_delayed_update_inode+0x120/0x130 [btrfs]
Jul  5 13:54:02 oglaroon kernel: [ 2657.663516]  RSP 88023010dbd8
Jul  5 13:54:02 oglaroon kernel: [ 2657.705561] ---[ end trace
0ae6cc23c8022b5b ]---

I was testing some completely different modifications I made myself, but
I'm quite certain that my changes did not trigger this error. With the
fs I could reproducably get to this bug by creating 10 reflinks of a
certain file in a shell loop.

I lost the file system while trying to setup a clean, tight test case.
The fs I used had something like 50 files, some reflinks and a snapshot
with some files deleted. The tree had explicit backrefs and shared backrefs.

Anyway, I could not setup a new file system triggering this bug. The
line that 

BTRFS Wiki

2011-07-05 Thread Jonathan Rogers
The Wiki at URL:https://btrfs.wiki.kernel.org/ seems to be having
trouble. For the past few days, it's often failed to load for me.
Sometimes the HTTP request times out. Sometimes I get an error page
indicating connection problems to the database server. Sometimes, pages
load quickly. This is an example of an error message I sometimes get:

((Can't contact the database server: No working slave server: Unknown
error (127.0.0.1:4040))

-- 
Jonathan Rogers

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


infinite loop when remounting a btrfs root filesystem read-write

2011-07-05 Thread Bernhard Rosenkranzer
Hi,
I've run into a severe problem with a btrfs root filesystem (this is
on 2.6.39, but other kernel versions seem to behave the same).
The filesystem mounts read-only fine, but trying to mount it
read-write causes an infinite loop inside the kernel, causing an
infinite repetition of the message

inode 57783233 still on the orphan list

in printk output.

To make things worse, btrfsck doesn't help - it runs for a couple of
minutes, prints a couple of errors, then aborts after saying

failed to find block number 1974534356992

There appears to be a bad block on the harddisk, but I doubt that sort
of overreaction is intended.
Is there any way to recover this filesystem short of rsync-ing it to a
different box while mounted read-only and reinstalling?

Thanks,
bero
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] scrub updates for 3.1

2011-07-05 Thread Li Zefan
21:00, Arne Jansen worte:
 Hi Chris,
 
 since rc-6 seems to be the last rc for 3.0 and in case you're already
 preparing your pull request for 3.1, can you please pull the following
 updates for scrub, based on your for-linus tree (2f7e33d432)?
 
 git://git.kernel.org/pub/scm/linux/kernel/git/arne/btrfs-unstable-arne.git
 for-chris
 
 It just contains the readahead patch, which gives a significant
 performance improvement for scrub. Currently scrub is the only
 consumer.
 
 Thanks,
 Arne
 
 Arne Jansen (7):
   btrfs: add an extra wait mode to read_extent_buffer_pages
   btrfs: add READAHEAD extent buffer flag
   btrfs: state information for readahead
   btrfs: initial readahead code and prototypes
   btrfs: hooks for readahead
   btrfs: test ioctl for readahead

Do we really want this ioctl that is merely for testing some kernel
APIs in our upstream kernel?

   btrfs: use readahead API for scrub
 
  fs/btrfs/Makefile|3 +-
  fs/btrfs/ctree.h |   21 ++
  fs/btrfs/disk-io.c   |   85 +-
  fs/btrfs/disk-io.h   |2 +
  fs/btrfs/extent_io.c |9 +-
  fs/btrfs/extent_io.h |4 +
  fs/btrfs/ioctl.c |   93 +-
  fs/btrfs/ioctl.h |   16 +
  fs/btrfs/reada.c |  949
 ++
  fs/btrfs/scrub.c |  116 +++
  fs/btrfs/volumes.c   |8 +
  fs/btrfs/volumes.h   |8 +
  12 files changed, 1239 insertions(+), 75 deletions(-)
  create mode 100644 fs/btrfs/reada.c
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] scrub updates for 3.1

2011-07-05 Thread Chris Mason
Excerpts from Li Zefan's message of 2011-07-05 21:06:02 -0400:
 21:00, Arne Jansen worte:
  Hi Chris,
  
  since rc-6 seems to be the last rc for 3.0 and in case you're already
  preparing your pull request for 3.1, can you please pull the following
  updates for scrub, based on your for-linus tree (2f7e33d432)?
  
  git://git.kernel.org/pub/scm/linux/kernel/git/arne/btrfs-unstable-arne.git
  for-chris
  
  It just contains the readahead patch, which gives a significant
  performance improvement for scrub. Currently scrub is the only
  consumer.
  
  Thanks,
  Arne
  
  Arne Jansen (7):
btrfs: add an extra wait mode to read_extent_buffer_pages
btrfs: add READAHEAD extent buffer flag
btrfs: state information for readahead
btrfs: initial readahead code and prototypes
btrfs: hooks for readahead
btrfs: test ioctl for readahead
 
 Do we really want this ioctl that is merely for testing some kernel
 APIs in our upstream kernel?

I'd like to avoid the ioctl for now, since once it is there we're stuck
with it forever.  At least for the 3.1 pull lets keep it out please.

-chris
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [BUG] delayed inodes and reflinks

2011-07-05 Thread Miao Xie
On tue, 05 Jul 2011 15:25:12 +0200, Jan Schmidt wrote:
 I hit this bug an hour ago while executing some cp --reflink:
 
 Jul  5 13:54:02 oglaroon kernel: [ 2654.545244] [ cut here
 ]
 Jul  5 13:54:02 oglaroon kernel: [ 2654.600508] kernel BUG at
 fs/btrfs/delayed-inode.c:1637!
[SNIP]
 Jul  5 13:54:02 oglaroon kernel: [ 2656.485403] Call Trace:
 Jul  5 13:54:02 oglaroon kernel: [ 2656.514742]  [a01db4de]
 btrfs_update_inode+0x3e/0x150 [btrfs]
 Jul  5 13:54:02 oglaroon kernel: [ 2656.593884]  [a0209160]
 btrfs_ioctl_clone+0x9e0/0xca0 [btrfs]
 Jul  5 13:54:02 oglaroon kernel: [ 2656.673022]  [81151f00] ?
 might_fault+0x40/0xa0
 Jul  5 13:54:02 oglaroon kernel: [ 2656.737613]  [a0209b05]
 btrfs_ioctl+0x335/0xf70 [btrfs]
 Jul  5 13:54:02 oglaroon kernel: [ 2656.810612]  [81151f57] ?
 might_fault+0x97/0xa0
 Jul  5 13:54:02 oglaroon kernel: [ 2656.875198]  [81151f0e] ?
 might_fault+0x4e/0xa0
 Jul  5 13:54:02 oglaroon kernel: [ 2656.939782]  [81859006] ?
 _raw_spin_unlock+0x26/0x30
 Jul  5 13:54:02 oglaroon kernel: [ 2657.009567]  [8117fcd3] ?
 cp_new_stat+0xf3/0x110
 Jul  5 13:54:02 oglaroon kernel: [ 2657.075325]  [8118cb5c]
 do_vfs_ioctl+0x9c/0x560
 Jul  5 13:54:02 oglaroon kernel: [ 2657.139982]  [818607ac] ?
 sysret_check+0x27/0x62
 Jul  5 13:54:02 oglaroon kernel: [ 2657.205604]  [8118d0b9]
 sys_ioctl+0x99/0xa0
 Jul  5 13:54:02 oglaroon kernel: [ 2657.266133]  [8186077b]
 system_call_fastpath+0x16/0x1b
 Jul  5 13:54:02 oglaroon kernel: [ 2657.337995] Code: f8 05 00 00 8d 0c
 49 48 89 ca 48 89 4d c8 e8 c8 c7 f9 ff 85 c0 48 8b 4d c8 75 10 48 89 4b
 08 e9 3d ff ff ff 0f 1f 80 00 00 00 00 0f 0b eb fe 66 66 66 2e 0f 1f
 84 00 00 00 00 00 55 48 89 e5 41
 Jul  5 13:54:02 oglaroon kernel: [ 2657.570642] RIP
 [a0222490] btrfs_delayed_update_inode+0x120/0x130 [btrfs]
 Jul  5 13:54:02 oglaroon kernel: [ 2657.663516]  RSP 88023010dbd8
 Jul  5 13:54:02 oglaroon kernel: [ 2657.705561] ---[ end trace
 0ae6cc23c8022b5b ]---
 
 I was testing some completely different modifications I made myself, but
 I'm quite certain that my changes did not trigger this error. With the
 fs I could reproducably get to this bug by creating 10 reflinks of a
 certain file in a shell loop.
 
 I lost the file system while trying to setup a clean, tight test case.
 The fs I used had something like 50 files, some reflinks and a snapshot
 with some files deleted. The tree had explicit backrefs and shared backrefs.
 
 Anyway, I could not setup a new file system triggering this bug. The
 line that triggered is the BUG_ON in btrfs_delayed_update_inode (line
 1693 in for-linus branch). We seem to have missed some reservation in
 some special case. The patch Miao sent some days ago does not
 interrelate at first sight.

I think you are right. btrfs_ioctl_clone() didn't reserve enough space because
we need reserve space for 3 items at least not 1 item:

  1 for old extents that will be dropped(in the some case, we may need more)
  1 for the new extent
  1 for the i-node

Maybe we need search the fs tree and find how many old extent need be dropped
and then reserve free space accurately

Thanks
Miao

 
 If I get back to a situation where I can reproduce the bug, I'll send a
 follow up.
 
 -Jan
 --
 To unsubscribe from this list: send the line unsubscribe linux-btrfs in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html