bug: missing snapshot as in the btrfs subvolume list command
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
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
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
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
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
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
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
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
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