btrfs error after using kernel 3.0-rc1
While using btrfs as root on kernel 3.0-rc1, there was some errors (I wasn't able to capture the error) that forced me to do hard reset. Now during startup system drops to busybox shell because it's unable to mount root partition. Is there a way to recover the data, as at least grub2 was still happy enough to load kernel and initrd (both of which located on the same btrfs partition)? This is what dmesg says [4.536798] device label SSD-ROOT devid 1 transid 38245 /dev/sda2 [9.552086] device label SSD-ROOT devid 1 transid 38245 /dev/disk/by-label/SSD-ROOT [9.554563] btrfs: disk space caching is enabled [9.564301] parent transid verify failed on 44040192 wanted 38240 found 32526 [9.564535] parent transid verify failed on 44040192 wanted 38240 found 32526 [9.564778] parent transid verify failed on 44040192 wanted 38240 found 32526 [9.575679] parent transid verify failed on 44052480 wanted 38240 found 31547 [9.575904] parent transid verify failed on 44052480 wanted 38240 found 31547 [9.576176] parent transid verify failed on 44052480 wanted 38240 found 31547 [9.586121] parent transid verify failed on 44064768 wanted 38240 found 34145 [9.586319] parent transid verify failed on 44064768 wanted 38240 found 34145 [9.586515] parent transid verify failed on 44064768 wanted 38240 found 34145 [9.587027] parent transid verify failed on 44068864 wanted 38240 found 34476 [9.589732] Btrfs detected SSD devices, enabling SSD mode [9.592923] block group 29360128 has an wrong amount of free space [9.592959] btrfs: failed to load free space cache for block group 29360128 [9.601802] [ cut here ] [9.601835] kernel BUG at fs/btrfs/inode.c:4582! [9.601867] invalid opcode: [#1] SMP [9.601896] Modules linked in: nbd btrfs zlib_deflate libcrc32c i915 drm_kms_helper drm tg3 i2c_algo_bit video ahci libahci [9.601983] [9.601996] Pid: 319, comm: exe Not tainted 3.0.0-rc1 #2 Hewlett-Packard HP Compaq 2210b/0ABC [9.602054] EIP: 0060:[] EFLAGS: 00010282 CPU: 0 [9.602104] EIP is at btrfs_add_link+0x1b8/0x240 [btrfs] [9.602140] EAX: ffef EBX: f4baeb44 ECX: 007d EDX: 007c [9.602176] ESI: 00b5 EDI: f4052b44 EBP: f46bbba0 ESP: f46bbb40 [9.602212] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [9.602245] Process exe (pid: 319, ti=f46ba000 task=f7052610 task.ti=f46ba000) [9.602288] Stack: [9.602303] 000a f4baeb44 f46bbb83 0001 00b5 f89f58af f46bbba0 [9.602359] f89e4910 f46bbb90 0982 f4018000 f4563800 f4baea20 f4052b44 [9.602415] 7e01 02ee 0100 fdf0 f482f2a0 [9.602471] Call Trace: [9.602499] [] ? unmap_extent_buffer+0xf/0x20 [btrfs] [9.602551] [] ? btrfs_inode_ref_index+0xe0/0xf0 [btrfs] [9.602598] [] add_inode_ref+0x2d9/0x380 [btrfs] [9.602642] [] replay_one_buffer+0x226/0x2f0 [btrfs] [9.602687] [] walk_down_log_tree+0x1d9/0x370 [btrfs] [9.602737] [] walk_log_tree+0xa1/0x1c0 [btrfs] [9.602778] [] ? radix_tree_lookup+0xa/0x10 [9.602823] [] btrfs_recover_log_trees+0x1e4/0x2b0 [btrfs] [9.602872] [] ? replay_one_extent+0x6b0/0x6b0 [btrfs] [9.602918] [] open_ctree+0x1261/0x15e0 [btrfs] [9.602957] [] ? strlcpy+0x39/0x50 [9.604434] [] btrfs_mount+0x4a2/0x5d0 [btrfs] [9.605678] [] ? ida_get_new_above+0x11e/0x1a0 [9.605678] [] mount_fs+0x3a/0x180 [9.605678] [] ? __alloc_percpu+0xf/0x20 [9.605678] [] vfs_kern_mount+0x4b/0xa0 [9.605678] [] do_kern_mount+0x3e/0xe0 [9.605678] [] do_mount+0x596/0x6c0 [9.605678] [] ? copy_mount_options+0xa8/0x110 [9.605678] [] sys_mount+0x6b/0xa0 [9.605678] [] sysenter_do_call+0x12/0x28 [9.605678] Code: 24 14 8b 45 d0 89 7c 24 08 89 54 24 0c 8b 55 d4 89 0c 24 8b 4d 08 e8 d8 ab fe ff 85 c0 0f 84 e4 fe ff ff 83 c4 54 5b 5e 5f 5d c3 <0f> 0b 8b 55 dc 8d 7d e3 b9 11 00 00 00 8b b2 dc fe ff ff 8b 55 [9.605678] EIP: [] btrfs_add_link+0x1b8/0x240 [btrfs] SS:ESP 0068:f46bbb40 [9.622016] ---[ end trace d5d085f53c746e86 ]--- -- Fajar -- 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: [PATCH v1 1/3] btrfs: remove struct btrfs_root parameter where unused
Hi, (2011/05/31 19:16), Arne Jansen wrote: > The following functions had a struct btrfs_root * parameter which went > unused: > > btrfs_set_block_group_rw > btrfs_destroy_delayed_refs > btrfs_csum_data > extent_data_ref_count > copy_to_sk > > Signed-off-by: Arne Jansen > --- > fs/btrfs/compression.c |3 +-- > fs/btrfs/ctree.c| 20 ++-- > fs/btrfs/ctree.h|5 + > fs/btrfs/disk-io.c | 14 ++ > fs/btrfs/disk-io.h |2 +- > fs/btrfs/extent-tree.c | 16 ++-- > fs/btrfs/file-item.c|3 +-- > fs/btrfs/free-space-cache.c |6 +++--- > fs/btrfs/inode.c|7 +++ > fs/btrfs/ioctl.c|5 ++--- > fs/btrfs/relocation.c |2 +- > fs/btrfs/scrub.c|7 +++ > 12 files changed, 38 insertions(+), 52 deletions(-) > > diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c > index bfe42b0..2182cc5 100644 > --- a/fs/btrfs/compression.c > +++ b/fs/btrfs/compression.c > @@ -105,7 +105,6 @@ static int check_compressed_csum(struct inode *inode, >u64 disk_start) > { > int ret; > - struct btrfs_root *root = BTRFS_I(inode)->root; > struct page *page; > unsigned long i; > char *kaddr; > @@ -120,7 +119,7 @@ static int check_compressed_csum(struct inode *inode, > csum = ~(u32)0; > > kaddr = kmap_atomic(page, KM_USER0); > - csum = btrfs_csum_data(root, kaddr, csum, PAGE_CACHE_SIZE); > + csum = btrfs_csum_data(kaddr, csum, PAGE_CACHE_SIZE); > btrfs_csum_final(csum, (char *)&csum); > kunmap_atomic(kaddr, KM_USER0); > > diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c > index b0e18d9..670bed7 100644 > --- a/fs/btrfs/ctree.c > +++ b/fs/btrfs/ctree.c > @@ -339,7 +339,7 @@ static noinline int update_ref_for_cow(struct > btrfs_trans_handle *trans, > BUG_ON(ret); > } > if (new_flags != 0) { > - ret = btrfs_set_disk_extent_flags(trans, root, > + ret = btrfs_set_disk_extent_flags(trans, > buf->start, > buf->len, > new_flags, 0); > @@ -1763,7 +1763,7 @@ done: > * fixing up the blocks in ram so the tree is consistent. > */ > static int fixup_low_keys(struct btrfs_trans_handle *trans, > - struct btrfs_root *root, struct btrfs_path *path, > + struct btrfs_path *path, > struct btrfs_disk_key *key, int level) 'trans' is also unnecessary in fixup_low_keys(). (http://marc.info/?l=linux-btrfs&m=130337980625475&w=2) Thanks, Tsutomu > { > int i; > @@ -1814,7 +1814,7 @@ int btrfs_set_item_key_safe(struct btrfs_trans_handle > *trans, > btrfs_set_item_key(eb, &disk_key, slot); > btrfs_mark_buffer_dirty(eb); > if (slot == 0) > - fixup_low_keys(trans, root, path, &disk_key, 1); > + fixup_low_keys(trans, path, &disk_key, 1); > return 0; > } > > @@ -2579,7 +2579,7 @@ static noinline int __push_leaf_left(struct > btrfs_trans_handle *trans, > clean_tree_block(trans, root, right); > > btrfs_item_key(right, &disk_key, 0); > - wret = fixup_low_keys(trans, root, path, &disk_key, 1); > + wret = fixup_low_keys(trans, path, &disk_key, 1); > if (wret) > ret = wret; > > @@ -2966,7 +2966,7 @@ again: > path->nodes[0] = right; > path->slots[0] = 0; > if (path->slots[1] == 0) { > - wret = fixup_low_keys(trans, root, > + wret = fixup_low_keys(trans, > path, &disk_key, 1); > if (wret) > ret = wret; > @@ -3301,7 +3301,7 @@ int btrfs_truncate_item(struct btrfs_trans_handle > *trans, > btrfs_set_disk_key_offset(&disk_key, offset + size_diff); > btrfs_set_item_key(leaf, &disk_key, slot); > if (slot == 0) > - fixup_low_keys(trans, root, path, &disk_key, 1); > + fixup_low_keys(trans, path, &disk_key, 1); > } > > item = btrfs_item_nr(leaf, slot); > @@ -3532,7 +3532,7 @@ int btrfs_insert_some_items(struct btrfs_trans_handle > *trans, > ret = 0; > if (slot == 0) { > btrfs_cpu_key_to_disk(&disk_key, cpu_key); > - ret = fixup_low_keys(trans, root, path, &disk_key, 1); > + ret = fixup_low_keys(trans, path, &disk_key, 1); > } > > if (btrfs_leaf_free_space(root, leaf) < 0) { > @@ -3638,7 +3638,7 @@ int setup_items_for_insert(struct
Re: [PATCH v2 0/7] Btrfs: New inode number allocator
On Monday 25 April 2011 10:57:47 Li Zefan wrote: > Currently btrfs stores the highest objectid of the fs tree, and it always > returns (highest+1) inode number when we create a file, so inode numbers > won't be reclaimed when we delete files, so we'll run out of inode numbers > as we keep create/delete files in 32bits machines. > > This patchset aims to fix this, and it works similar to free space caching > for block groups. > > I've run xfstests, and I also tested it with snapshot, balance etc. > > More testing is appreciated! > > Changelog v2: > > - Rebased against latest btrfs-unstable tree > - Fixed several small bugs. > > --- > fs/btrfs/btrfs_inode.h |9 + > fs/btrfs/compression.c |5 +- > fs/btrfs/ctree.h| 29 +- > fs/btrfs/disk-io.c | 19 + > fs/btrfs/export.c | 25 +- > fs/btrfs/extent-tree.c | 50 ++- > fs/btrfs/extent_io.c|4 +- > fs/btrfs/file-item.c|5 +- > fs/btrfs/file.c | 27 +- > fs/btrfs/free-space-cache.c | 968 > ++- fs/btrfs/free-space-cache.h | > 48 ++- > fs/btrfs/inode-map.c| 428 +++- > fs/btrfs/inode-map.h| 13 + > fs/btrfs/inode.c| 282 +++-- > fs/btrfs/ioctl.c| 22 +- > fs/btrfs/relocation.c | 27 +- > fs/btrfs/transaction.c | 13 +- > fs/btrfs/tree-log.c | 54 ++-- > fs/btrfs/xattr.c|8 +- > 19 files changed, 1402 insertions(+), 634 deletions(-) This makes my laptop unusable here. With linux-3.0-rc1 I have the problem that booting is horrible slow with very much IO (the kernel thread that reads the file tree?). I've never tried how long it would take to boot the system. After 10-15 minutes I've canceled the boot (sysrq-u, sysrq-b) and took a working kernel. git bisect pointed me to: commit 581bb050941b4f220f84d3e5ed6dace3d42dd382 Author: Li Zefan Date: Wed Apr 20 10:06:11 2011 +0800 Btrfs: Cache free inode numbers in memory Currently btrfs stores the highest objectid of the fs tree, and it always returns (highest+1) inode number when we create a file, so inode numbers won't be reclaimed when we delete files, so we'll run out of inode numbers as we keep create/delete files in 32bits machines. This fixes it, and it works similarly to how we cache free space in block cgroups. We start a kernel thread to read the file tree. By scanning inode items, we know which chunks of inode numbers are free, and we cache them in an rb-tree. Because we are searching the commit root, we have to carefully handle the cross-transaction case. The rb-tree is a hybrid extent+bitmap tree, so if we have too many small chunks of inode numbers, we'll use bitmaps. Initially we allow 16K ram of extents, and a bitmap will be used if we exceed this threshold. The extents threshold is adjusted in runtime. Signed-off-by: Li Zefan I have three subvolumes here, the default one, one for / and one for /home. Don't know if this matters. If you need more infos, please tell me. regards, Johannes -- 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
[PATCH] Btrfs: don't save the inode cache if we are deleting this root
With xfstest 254 I can panic the box every time with the inode number caching stuff on. This is because we clean the inodes out when we delete the subvolume, but then we write out the inode cache which adds an inode to the subvolume inode tree, and then when it gets evicted again the root gets added back on the dead roots list and is deleted again, so we have a double free. To stop this from happening just return 0 if refs is 0 (and we're not the tree root since tree root always has refs of 0). With this fix 254 no longer panics. Thanks, Signed-off-by: Josef Bacik --- fs/btrfs/inode-map.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/fs/btrfs/inode-map.c b/fs/btrfs/inode-map.c index 3262cd1..2835375 100644 --- a/fs/btrfs/inode-map.c +++ b/fs/btrfs/inode-map.c @@ -388,6 +388,11 @@ int btrfs_save_ino_cache(struct btrfs_root *root, int prealloc; bool retry = false; + /* Don't save inode cache if we are deleting this root */ + if (btrfs_root_refs(&root->root_item) == 0 && + root != root->fs_info->tree_root) + return 0; + path = btrfs_alloc_path(); if (!path) return -ENOMEM; -- 1.7.2.3 -- 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: strange btrfs sub list output
On Tue, May 31, 2011 at 1:50 PM, Andreas Philipp wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 31.05.2011 19:40, C Anthony Risinger wrote: >> On Tue, May 31, 2011 at 5:00 AM, Stephane Chazelas >> wrote: >>> 2011-05-27 13:49:52 +0200, Andreas Philipp: [...] > Thanks, I can understand that. What I don't get is how one > creates a subvol with a top-level other than 5. I might be > missing the obvious, though. > > If I do: > > btrfs sub create A btrfs sub create A/B btrfs sub snap A > A/B/C > > A, A/B, A/B/C have their top-level being 5. How would I get a > new snapshot to be a child of A/B for instance? > > In my case, 285, was not appearing in the btrfs sub list > output, 287 was a child of 285 with path "data" while all I > did was create a snapshot of 284 (path > u6:10022/vm+xfs@u8/xvda1/g8/v3/data in vol 5) in > u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30 > > So I did manage to get a volume with a parent other than 5, > but I did not ask for it. >>> [...] Reconsidering the explanations on btrfs subvolume list in this thread I get the impression that a line in the output of btrfs subvolume list with top level other than 5 indicates that the backrefs from one subvolume to its parent are broken. What's your opinion on this? >>> [...] >>> >>> Given that I don't really get what the parent-child relationship >>> means in that context, I can't really comment. >>> >>> In effect, the snapshot had been created and was attached to the >>> right directory (but didn't appear in the sub list), and there >>> was an additional "data" volume that I had not asked for nor >>> created that had the snapshot above as parent and that did appear >>> in the sub list. >>> >>> It pretty much looks like a bug to me, I'd like to understand >>> more so that I can maybe try and avoid running into it again. >> >> i'm actually really interested in the conclusion to this thread >> because i _want_ to create subvols with a new parent ... i didn't >> realize this wasn't possible (nor the mount option) until reading >> this thread. this would give me a little more flexibility with >> initcpio hooks and the like vs. packing the btrfs root with tons of >> hidden files [subvols] or using IDs directly ... >> >> i tried absolutely everything i could think of to reproduce this >> but all subvols ended up having a top level id of `5`. >> >> ... so, is there any known way to _purposefully_ create parented >> subvols with the current tools? > > Hopefully, I can help clarify this a little bit. In fact, this is the > 'usual' case. With the attached patch to the master branch of > btrfs-progs-unstable you can 'watch' how the btrfs subvolume list > command builds the full path of the listed subvolumes. Additionally, > it gives you the IDs of the parent subvolumes. See the following example. > > ID 256 top level 5 path test1 > ID 257 top level 256 path test1.1 > ID 257 top level 5 path test1/test1.1 > ID 258 top level 5 path test2 > ID 259 top level 258 path test2.1 > ID 259 top level 5 path test2/test2.1 > > - From the second line you see that subvolume ID 256 really is ID 257's > parent. Additionally, only test1 and test2 have parent ID 5 or in your > terminology are in the btrfs root. aaah, ok ... this is what i thought was happening too after taking a peek at the sources (albeit i don't write any C) and seems to match what Hugo was saying if i understand him correctly. this also makes sense what you said about a broken link ... since normally the `btrfs` tool will not let you remove a subvol that has other subvols nested within it ... though *technically* it does not seem to matter, yes? must have been a fluke/bug in the `btrfs` tool where a higher level subvol was removed before it's child somehow, is this correct? or is the FS itself slightly broken when this happens? yeah i know that's kind of "my terminology" :-) ... i've spent a lot of time explaining btrfs concepts to others and that term always seemed to makes the most sense to people ... `top-level` can change, `default` can change, etc, etc ... but `the btrfs root` can only mean one thing -- the most "bottomest" of the bottom (or top, if you prefer :-) i'll try this out later tonight, thanks. ... which brings me to a question i've asked a few times in the past -- will it ever be possible to "replace" subvolid=5 with a different subvol? or drop it's contents SAFELY somehow? lack of this ability makes it very difficult to rotate a user into an advanced configuration if they did not install their system into a subvolume to begin with, and no distro AFAIK does this for them; last time i tried to `mv` the users installation to an empty subvol it copied everything for hours ... though this could be fixed already, or possibly alleviated with `cp --reflink`, i haven't tried for awhile. i'd like to avoid telling users "ok, now you just need to rm -rf all
Re: [PATCH 0/9] some fixes for bugs spotted by valgrind
Some clarifications: > Patchset based on 'tmp' branch e6bd18d8938986c997c45f0ea95b221d4edec095. All patches are against btrfs-progs. The rest of rambling is about kernel code, which handles supers. I have read what I've wrote last night (braindump of insane!) and will try to elaborate a bit: > Poking at valgrind warnings I have noticed very worrying problem. > When we (over)write superblock we take 4096 continuous bytes in memory. The common pattern in disk-io.c is the following: struct btrfs_super_block *sb = root->fs_info->sb // or ->sb_for_commit memcpy(dest, sb, BTRFS_SUPER_INFO_SIZE /* 4096 */); With a memcpy we go out of sizeof(*sb) (~2.5K) and pick more fields from fs_info struct. Let's look at them: struct btrfs_fs_info { ... struct btrfs_super_block super_copy; struct btrfs_super_block super_for_commit; struct block_device *__bdev; struct super_block *sb; struct inode *btree_inode; struct backing_dev_info bdi; struct mutex trans_mutex; struct mutex tree_log_mutex; struct mutex transaction_kthread_mutex; struct mutex cleaner_mutex; struct mutex chunk_mutex; struct mutex volume_mutex; struct mutex ordered_operations_mutex; struct rw_semaphore extent_commit_sem; struct rw_semaphore cleanup_work_sem; struct rw_semaphore subvol_sem; struct srcu_struct subvol_srcu; struct list_head trans_list; struct list_head hashers; struct list_head dead_roots; struct list_head caching_block_groups; spinlock_t delayed_iput_lock; struct list_head delayed_iputs; atomic_t nr_async_submits; ... So we copyout (and even checksum!) atomic counters and other volatile stuff (I haven't looked at mutexes and semaphores, but i'm sure there is yet some volatile stuff) > In kernel the structures reside in btrfs_fs_info structure, so we compute > CRC for: > struct btrfs_super_block super_copy; > struct btrfs_super_block super_for_commit; > and then write it to disk. [H]ere we have 2 issues: > 1. kernel pointers and other random stuff leaks out to kernel. >It's nondeterministic and leaks out data (not too bad, >as it should be accessible only for root, but still) > 2. more serious: is there guarantee, that noone will kick-in >between CRC computation and superblock outwrite? > >What if some of mutexes, semaphores or lists will change >it's internal state? Some async thread will kick it >an we will end-up writing superblock with invalid CRC! >This might well be the cause of recend superblock >corruptions under heavy load + hangup retorted to the list. > > Consider the following call chain: > [somewhere in write_dev_supers ...] > > bh->b_end_io = btrfs_end_buffer_write_sync; > crc = ~(u32)0; > crc = btrfs_csum_data(NULL, (char *)sb + > BTRFS_CSUM_SIZE, crc, > BTRFS_SUPER_INFO_SIZE - > BTRFS_CSUM_SIZE); > btrfs_csum_final(crc, sb->csum); Now the problem should be a bit more clear: sb is a thing pointing to the middle of fs_info. We checksum it with data after it in fs_info. > bh = __getblk(device->bdev, bytenr / 4096, > BTRFS_SUPER_INFO_SIZE); > > memcpy(bh->b_data, sb, BTRFS_SUPER_INFO_SIZE); and here we write all the checksummed contents. Is there guard, which prevents things from updating fs_info? > > /* one reference for submit_bh */ > get_bh(bh); > > set_buffer_uptodate(bh); > lock_buffer(bh); > bh->b_end_io = btrfs_end_buffer_write_sync; Am I too paranoid about the issue? Thanks! -- Sergei signature.asc Description: PGP signature
Re: strange btrfs sub list output
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31.05.2011 19:40, C Anthony Risinger wrote: > On Tue, May 31, 2011 at 5:00 AM, Stephane Chazelas > wrote: >> 2011-05-27 13:49:52 +0200, Andreas Philipp: [...] Thanks, I can understand that. What I don't get is how one creates a subvol with a top-level other than 5. I might be missing the obvious, though. If I do: btrfs sub create A btrfs sub create A/B btrfs sub snap A A/B/C A, A/B, A/B/C have their top-level being 5. How would I get a new snapshot to be a child of A/B for instance? In my case, 285, was not appearing in the btrfs sub list output, 287 was a child of 285 with path "data" while all I did was create a snapshot of 284 (path u6:10022/vm+xfs@u8/xvda1/g8/v3/data in vol 5) in u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30 So I did manage to get a volume with a parent other than 5, but I did not ask for it. >> [...] >>> Reconsidering the explanations on btrfs subvolume list in this >>> thread I get the impression that a line in the output of btrfs >>> subvolume list with top level other than 5 indicates that the >>> backrefs from one subvolume to its parent are broken. >>> >>> What's your opinion on this? >> [...] >> >> Given that I don't really get what the parent-child relationship >> means in that context, I can't really comment. >> >> In effect, the snapshot had been created and was attached to the >> right directory (but didn't appear in the sub list), and there >> was an additional "data" volume that I had not asked for nor >> created that had the snapshot above as parent and that did appear >> in the sub list. >> >> It pretty much looks like a bug to me, I'd like to understand >> more so that I can maybe try and avoid running into it again. > > i'm actually really interested in the conclusion to this thread > because i _want_ to create subvols with a new parent ... i didn't > realize this wasn't possible (nor the mount option) until reading > this thread. this would give me a little more flexibility with > initcpio hooks and the like vs. packing the btrfs root with tons of > hidden files [subvols] or using IDs directly ... > > i tried absolutely everything i could think of to reproduce this > but all subvols ended up having a top level id of `5`. > > ... so, is there any known way to _purposefully_ create parented > subvols with the current tools? Hopefully, I can help clarify this a little bit. In fact, this is the 'usual' case. With the attached patch to the master branch of btrfs-progs-unstable you can 'watch' how the btrfs subvolume list command builds the full path of the listed subvolumes. Additionally, it gives you the IDs of the parent subvolumes. See the following example. ID 256 top level 5 path test1 ID 257 top level 256 path test1.1 ID 257 top level 5 path test1/test1.1 ID 258 top level 5 path test2 ID 259 top level 258 path test2.1 ID 259 top level 5 path test2/test2.1 - From the second line you see that subvolume ID 256 really is ID 257's parent. Additionally, only test1 and test2 have parent ID 5 or in your terminology are in the btrfs root. diff --git a/btrfs-list.c b/btrfs-list.c index 93766a8..e75d6cf 100644 - --- a/btrfs-list.c +++ b/btrfs-list.c @@ -248,6 +248,9 @@ static int resolve_root(struct root_lookup *rl, struct root_info *ri) top_id = next; break; } + + printf("ID %llu top level %llu path %s\n", ri->root_id, next, + full_path); } printf("ID %llu top level %llu path %s\n", ri->root_id, top_id, full_path); -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN5Th6AAoJEJIcBJ3+XkgiWNQP/jsWQymukrgESfqndQvrJwl6 QZOe5y9IMmV8jBDPot4EAVAQhLrG2twA1ALVvj+DfD0Ks9VATpmnP4QB39XIWlNz /cRxoUev/Z8a0zNnXXneUsbJ1rYx5vX6R0yzRWiZ6Yd0EZ9GCRp+HvPRs5NNGGIc 0NZCQk1BOe+MAovSQpUbRtyfd4JcxdPEYkt29VySu2wrD02MdXVyzohegCzmUZWv ou8COpWvquPmNvYHfudVir6r4BSEfqpIEkkGY61yts00rnnPXuOh1uZQKGyDuK/S 2o6EOAN3SIONEWts7nx95/IjfAbVa/XUmj+bhr2xJspH4Q93tr8rDns0XCCN/GYY xTfMMUFajZHOhv5qjbUF9BFLAU62eKdw4zCPAmed4f/klBcXZ/Ri1pIBwaJv3CTp J3camkJBwmTiSwTIIl1qTOMypv0xT602uiiegnBe/UAzz59+cSLDyWFXBc2QQoTV jhJiLd281kjPqEqALMNJOOZ0pQ6hDxOoBqg7cA5VEY9619coQE93H6UXgtd0E4YX U32bO7WypGbgd3HuNDWd44p4gVYR/Mzu8symvjJDKg5iChLkBEmYyN8hAGryYhtO mZBWntTxYPm+Twkf+ovAtVpLGV5Gr1kfGln5lsmsIn1bPW8ZnVbWIDhulD1lQSVw Th5rDp6lY0ZBe4+mbOXy =M8dp -END PGP SIGNATURE- -- 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: Problem with latest for-linus branch
2011/5/30 Chris Mason : > Ok, so I think we're blowing past the end of the page we've kmap'd. But > I don't think that can happen without something like the patch below > triggering: Quick update: after rm of ~10 GB of data, I rebooted with Linus' latest git tree, and it works (after some minutes of btrfs-ino-cache). Ciao, Andrea -- 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: linux-next: build warninga in Linus' tree
Hi, On Mon, May 30, 2011 at 11:36:53AM +1000, Stephen Rothwell wrote: > After merging the Linus' tree, today's linux-next build (powerpc > ppc64_defconfig) produced these warnings: > > fs/btrfs/sysfs.c:76:26: warning: 'btrfs_root_attrs' defined but not used > fs/btrfs/sysfs.c:97:26: warning: 'btrfs_super_attrs' defined but not used > fs/btrfs/sysfs.c:153:13: warning: 'btrfs_super_release' defined but not used > fs/btrfs/sysfs.c:160:13: warning: 'btrfs_root_release' defined but not used > > I have started using gcc v4.5.2 (instead of v4.4.4) if that makes a > difference. the warning probably started to show up after one of my cleanup patches, removing unused functions (f2a97a9dbd86eb1ef956bdf20e05c507b32beb96). The sysfs interface is not being used right now, but there's a unmerged patchset which adds the interesting bits like info about available btrfs filesystems and devices. I don't know what are the intentions regarding sysfs. david -- 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: [PATCH] btrfs: use btrfs_ino to access inode number
both patches are pushed to git://repo.or.cz/linux-2.6/btrfs-unstable.git #fixes david On Tue, May 31, 2011 at 07:08:14PM +0200, David Sterba wrote: > commit 4cb5300bc ("Btrfs: add mount -o auto_defrag") accesses inode > number directly while it should use the helper with the new inode > number allocator. > > Signed-off-by: David Sterba -- 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: strange btrfs sub list output
On Tue, May 31, 2011 at 5:00 AM, Stephane Chazelas wrote: > 2011-05-27 13:49:52 +0200, Andreas Philipp: > [...] >> > Thanks, I can understand that. What I don't get is how one creates >> > a subvol with a top-level other than 5. I might be missing the >> > obvious, though. >> > >> > If I do: >> > >> > btrfs sub create A btrfs sub create A/B btrfs sub snap A A/B/C >> > >> > A, A/B, A/B/C have their top-level being 5. How would I get a new >> > snapshot to be a child of A/B for instance? >> > >> > In my case, 285, was not appearing in the btrfs sub list output, >> > 287 was a child of 285 with path "data" while all I did was create >> > a snapshot of 284 (path u6:10022/vm+xfs@u8/xvda1/g8/v3/data in vol >> > 5) in u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30 >> > >> > So I did manage to get a volume with a parent other than 5, but I >> > did not ask for it. > [...] >> Reconsidering the explanations on btrfs subvolume list in this thread >> I get the impression that a line in the output of btrfs subvolume list >> with top level other than 5 indicates that the backrefs from one >> subvolume to its parent are broken. >> >> What's your opinion on this? > [...] > > Given that I don't really get what the parent-child relationship > means in that context, I can't really comment. > > In effect, the snapshot had been created and was attached to the > right directory (but didn't appear in the sub list), and there > was an additional "data" volume that I had not asked for nor > created that had the snapshot above as parent and that did > appear in the sub list. > > It pretty much looks like a bug to me, I'd like to understand > more so that I can maybe try and avoid running into it again. i'm actually really interested in the conclusion to this thread because i _want_ to create subvols with a new parent ... i didn't realize this wasn't possible (nor the mount option) until reading this thread. this would give me a little more flexibility with initcpio hooks and the like vs. packing the btrfs root with tons of hidden files [subvols] or using IDs directly ... i tried absolutely everything i could think of to reproduce this but all subvols ended up having a top level id of `5`. ... so, is there any known way to _purposefully_ create parented subvols with the current tools? -- C Anthony -- 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
[PATCH] btrfs: use btrfs_ino to access inode number
commit 4cb5300bc ("Btrfs: add mount -o auto_defrag") accesses inode number directly while it should use the helper with the new inode number allocator. Signed-off-by: David Sterba --- fs/btrfs/file.c |2 +- fs/btrfs/ioctl.c |7 --- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index 3ba6d19..dd4cb3e 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -144,7 +144,7 @@ int btrfs_add_inode_defrag(struct btrfs_trans_handle *trans, if (!defrag) return -ENOMEM; - defrag->ino = inode->i_ino; + defrag->ino = btrfs_ino(inode); defrag->transid = transid; defrag->root = root->root_key.objectid; diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 85e818c..1a7deca 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -707,16 +707,17 @@ static int find_new_extents(struct btrfs_root *root, struct btrfs_file_extent_item *extent; int type; int ret; + u64 ino = btrfs_ino(inode); path = btrfs_alloc_path(); if (!path) return -ENOMEM; - min_key.objectid = inode->i_ino; + min_key.objectid = ino; min_key.type = BTRFS_EXTENT_DATA_KEY; min_key.offset = *off; - max_key.objectid = inode->i_ino; + max_key.objectid = ino; max_key.type = (u8)-1; max_key.offset = (u64)-1; @@ -727,7 +728,7 @@ static int find_new_extents(struct btrfs_root *root, path, 0, newer_than); if (ret != 0) goto none; - if (min_key.objectid != inode->i_ino) + if (min_key.objectid != ino) goto none; if (min_key.type != BTRFS_EXTENT_DATA_KEY) goto none; -- 1.7.5.2.353.g5df3e -- 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
[PATCH] btrfs: add helper for fs_info->closing
wrap checking of filesystem 'closing' flag and fix a few missing memory barriers. Signed-off-by: David Sterba --- based on 'for-linus' branch of mason/btrfs-unstable.git fs/btrfs/ctree.h|9 + fs/btrfs/extent-tree.c |3 +-- fs/btrfs/file.c |4 ++-- fs/btrfs/free-space-cache.c | 10 -- fs/btrfs/inode-map.c|3 +-- fs/btrfs/inode.c|3 +-- fs/btrfs/scrub.c|2 +- fs/btrfs/transaction.c |2 +- 8 files changed, 20 insertions(+), 16 deletions(-) diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index 332323e..07482a47 100644 --- a/fs/btrfs/ctree.h +++ b/fs/btrfs/ctree.h @@ -2350,6 +2350,15 @@ int btrfs_drop_subtree(struct btrfs_trans_handle *trans, struct btrfs_root *root, struct extent_buffer *node, struct extent_buffer *parent); +static inline int btrfs_fs_closing(struct btrfs_fs_info *fs_info) +{ + /* +* Get synced with close_ctree() +*/ + smp_mb(); + return fs_info->closing; +} + /* root-item.c */ int btrfs_find_root_ref(struct btrfs_root *tree_root, struct btrfs_path *path, diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 169bd62..ce466da 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -366,8 +366,7 @@ again: nritems = btrfs_header_nritems(leaf); while (1) { - smp_mb(); - if (fs_info->closing > 1) { + if (btrfs_fs_closing(fs_info) > 1) { last = (u64)-1; break; } diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index c6a22d7..3ba6d19 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -129,7 +129,7 @@ int btrfs_add_inode_defrag(struct btrfs_trans_handle *trans, if (!btrfs_test_opt(root, AUTO_DEFRAG)) return 0; - if (root->fs_info->closing) + if (btrfs_fs_closing(root->fs_info)) return 0; if (BTRFS_I(inode)->in_defrag) @@ -229,7 +229,7 @@ int btrfs_run_defrag_inodes(struct btrfs_fs_info *fs_info) first_ino = defrag->ino + 1; rb_erase(&defrag->rb_node, &fs_info->defrag_inodes); - if (fs_info->closing) + if (btrfs_fs_closing(fs_info)) goto next_free; spin_unlock(&fs_info->defrag_inodes_lock); diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c index 70d4579..e65a8b0 100644 --- a/fs/btrfs/free-space-cache.c +++ b/fs/btrfs/free-space-cache.c @@ -98,7 +98,7 @@ struct inode *lookup_free_space_inode(struct btrfs_root *root, return inode; spin_lock(&block_group->lock); - if (!root->fs_info->closing) { + if (!btrfs_fs_closing(root->fs_info)) { block_group->inode = igrab(inode); block_group->iref = 1; } @@ -478,8 +478,7 @@ int load_free_space_cache(struct btrfs_fs_info *fs_info, * If we're unmounting then just return, since this does a search on the * normal root and not the commit root and we could deadlock. */ - smp_mb(); - if (fs_info->closing) + if (btrfs_fs_closing(fs_info)) return 0; /* @@ -2481,7 +2480,7 @@ struct inode *lookup_free_ino_inode(struct btrfs_root *root, return inode; spin_lock(&root->cache_lock); - if (!root->fs_info->closing) + if (!btrfs_fs_closing(root->fs_info)) root->cache_inode = igrab(inode); spin_unlock(&root->cache_lock); @@ -2508,8 +2507,7 @@ int load_free_ino_cache(struct btrfs_fs_info *fs_info, struct btrfs_root *root) * If we're unmounting then just return, since this does a search on the * normal root and not the commit root and we could deadlock. */ - smp_mb(); - if (fs_info->closing) + if (btrfs_fs_closing(fs_info)) return 0; path = btrfs_alloc_path(); diff --git a/fs/btrfs/inode-map.c b/fs/btrfs/inode-map.c index 3262cd1..41359bd 100644 --- a/fs/btrfs/inode-map.c +++ b/fs/btrfs/inode-map.c @@ -59,8 +59,7 @@ again: goto out; while (1) { - smp_mb(); - if (fs_info->closing) + if (btrfs_fs_closing(fs_info)) goto out; leaf = path->nodes[0]; diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index bb51bb1..66c1446 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -4268,8 +4268,7 @@ int btrfs_write_inode(struct inode *inode, struct writeback_control *wbc) if (BTRFS_I(inode)->dummy_inode) return 0; - smp_mb(); - if (root->fs_info->closing && is_free_space_inode(root, inode)) + if (btrfs_fs_closing(root->fs_info) && is_free_space_inode(root, inode)) noloc
[3.0-rc1] insert_dir_item hitting assertion during log replay
On 10 April 2011 16:29, Daniel J Blueman wrote: > When rebooting from a crash, thus during log replay on 2.6.29-rc2, > btrfs_insert_dir_item caused an assertion failure [1]. The fs was > being mounted clear_cache on an SSD. On 3.0-rc1 with a fresh filesystem, after a few crashes with other bugs, I tripped the assert at inode.c:4582 during log replay at mount time, ie btrfs_insert_dir_item() is returning non-zero. I have a metadata image captured from when this occurred in 2.6.29-rc2 and have instrumented the upstream functions to locate where we're failing if it happens in my debug session soon. Anything else we can do? Thanks, Daniel > --- [1] 2.6.29-rc2 trace > > kernel BUG at fs/btrfs/inode.c:4665! > invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC > last sysfs file: > /sys/devices/virtual/wmi/A80593CE-A997-11DA-B012-B622A1EF5492/uevent > CPU 3 > Modules linked in: video sdhci_pci sdhci mmc_core > > Pid: 328, comm: mount Not tainted 2.6.39-rc2-350cd+ #1 Dell Inc. > Latitude E5420/0H5TG2 > RIP: 0010:[] [] > btrfs_add_link+0x132/0x190 > RSP: 0018:88021e1097d8 EFLAGS: 00010282 > RAX: ffef RBX: 88021d965f70 RCX: 0006 > RDX: ffef RSI: 88021efe4710 RDI: 88021efe4020 > RBP: 88021e109848 R08: R09: 88022d7c03f0 > R10: 0001 R11: 0001 R12: 88021d966720 > R13: 88021e0261b0 R14: 000f R15: 88021d959000 > FS: 7fcee7b3d800() GS:88022ec6() knlGS: > CS: 0010 DS: ES: CR0: 8005003b > CR2: 7f5e5700 CR3: 00021e6ef000 CR4: 000406e0 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0400 > Process mount (pid: 328, threadinfo 88021e108000, task 88021efe4020) > Stack: > 88020001 0016 88021e109978 0016 > 0010555e 0001 1000 > 88021e03a000 00b0 88021e109ae8 > Call Trace: > [] add_inode_ref+0x2f5/0x3b0 > [] ? get_parent_ip+0x11/0x50 > [] replay_one_buffer+0x2c6/0x3a0 > [] ? mark_held_locks+0x70/0xa0 > [] ? get_parent_ip+0x11/0x50 > [] walk_up_log_tree+0x168/0x320 > [] ? replay_one_dir_item+0xe0/0xe0 > [] walk_log_tree+0xe8/0x290 > [] ? trace_hardirqs_on+0xd/0x10 > [] btrfs_recover_log_trees+0x220/0x320 > [] ? replay_one_dir_item+0xe0/0xe0 > [] open_ctree+0x1301/0x16b0 > [] ? snprintf+0x34/0x40 > [] btrfs_fill_super.clone.14+0x73/0x130 > [] ? disk_name+0x5f/0xc0 > [] ? strlcpy+0x47/0x60 > [] btrfs_mount+0x340/0x3e0 > [] mount_fs+0x1b/0xd0 > [] vfs_kern_mount+0x5e/0xd0 > [] do_kern_mount+0x4f/0x100 > [] do_mount+0x1e4/0x220 > [] sys_mount+0x8b/0xe0 > [] system_call_fastpath+0x16/0x1b > Code: 4c 89 d2 44 89 f1 4c 89 ee 4c 89 1c 24 4c 89 55 a8 4c 89 5d a0 > e8 5f c6 fe ff 4c 8b 5d a0 4c 8b 55 a8 85 c0 75 bc e9 31 ff ff ff <0f> > 0b 48 8b b2 d0 fc ff ff 48 8d 7d b0 b9 11 00 00 00 4d 89 d9 > RIP [] btrfs_add_link+0x132/0x190 > RSP -- Daniel J Blueman -- 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: kernel BUG at fs/btrfs/inode.c:149!
On 05/30/2011 07:12 AM, Elric Milon wrote: > On Monday 23 May 2011 21:51:57 Josef Bacik wrote: >> On 05/23/2011 07:57 AM, Elric Milon wrote: >>> On Monday 16 May 2011 18:28:49 you wrote: On 05/16/2011 11:01 AM, Whirm wrote: > On Monday 16 May 2011 16:11:19 Josef Bacik wrote: > > > Sorry yes, I meant this is how I managed to get the corrupted > filesystem. > > Ill try to break it again. Oh ok perfect, yeah I will try and do the same sort of things and see if I can get it to happen as well. Thanks, >>> >>> Great, btw, I tried to see if I can mount the corrupted filesystem with >>> the patch you told me about applied, and it fails, here's the log: >>> >>> http://pastebin.com/raw.php?i=4Kfv927B >>> >>> That happens using 2.6.39-rc7+ from git with the following patch applied >>> (its >> >>> the debug patch and the possible fix you told me about): >> Ok so this is a different kind of corruption, wooo! Can you apply this >> debug patch and get me the output so we can try and fix this bit? Thanks, >> >> Josef >> > > Sorry for the delay, here's the log: > > http://pastebin.com/raw.php?i=zNqJVpA1 > Ok so you have a corrupt extent entry in your tree. I will come up with something so we deal with this case better than panicing. Thanks for running these debug patches, Josef -- 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: [PATCH v1 0/3] btrfs: cleanup: pass fs_info instead of root where possible
3/3 doesn't seem to arrive anymore, possibly due to a mail size restriction on vger (yes, it is big). So I pushed it out to: git://git.kernel.org/pub/scm/linux/kernel/git/arne/btrfs-unstable-arne.git root-eliminate Thanks, Arne On 31.05.2011 12:16, Arne Jansen wrote: > This series aims to clean up passing of struct btrfs_root and struct > btrfs_fs_info. It first removes the root pointer from functions and macros > where it's not needed, afterwards it passes fs_info instead of root to > functions which only need root->fs_info. > > It is based on 3.0-rc1. > > These patches are based on the following two Coccinelle-scripts, but also > involve some hand editing. > > a) Remove root parameter where it's completely unneeded. Fix up callers. > > @r@ > identifier fn != btrfs_inc_extent_ref; > identifier root; > parameter list[n] P; > @@ > > fn(P > -, struct btrfs_root *root >,...) > { > ... when != root > } > > @@ > identifier r.fn; > expression list[r.n] E; > identifier x; > @@ > > fn(E > -,x >,...) > > b) Change root parameter to fs_info where only root->fs_info is needed. Fix up >callers. > > @ s exists @ > identifier fn; > identifier root, sf; > identifier member != fs_info; > position p; > expression E; > parameter list[n] P; > @@ > fn@p(P,struct btrfs_root *root,...) > { > ... > ( > root->member > | > sf(...,root,...) > | > (root && ...) > | > (root == ...) > | > E = root > ) > ... when any > } > > @ t @ > identifier fn != {process_one_buffer,btrfs_inc_extent_ref,btrfs_free_extent}; > identifier root; > parameter list[n] P; > position p != s.p; > @@ > > fn@p(P, > -struct btrfs_root *root > +struct btrfs_fs_info *fs_info >,...) > { > <... > - root->fs_info > + fs_info > ...> > } > > @@ > identifier t.fn; > expression list[t.n] E; > expression x; > @@ > > fn(E, > -x > +x->fs_info >,...) > > @@ > function fn; > identifier fs_info; > identifier x; > parameter list[n] P; > @@ > fn(P, struct btrfs_fs_info *fs_info, ... ) { > ... > - struct btrfs_fs_info *x = fs_info; > <... > - x > + fs_info > ...> > } > > > Thanks to Julia Lawall for helping to build the scripts. > > > Arne Jansen (3): > btrfs: remove struct btrfs_root parameter where unused > btrfs: pass fs_info to btrfs_test_opt instead of root > btrfs: cleanup: pass fs_info instead of root where possible > > fs/btrfs/compression.c | 11 +- > fs/btrfs/ctree.c| 76 + > fs/btrfs/ctree.h| 66 > fs/btrfs/delayed-inode.c| 43 +++--- > fs/btrfs/disk-io.c | 281 +++--- > fs/btrfs/disk-io.h | 24 ++-- > fs/btrfs/extent-tree.c | 409 > ++- > fs/btrfs/file-item.c|5 +- > fs/btrfs/file.c | 16 +- > fs/btrfs/free-space-cache.c | 12 +- > fs/btrfs/free-space-cache.h |2 +- > fs/btrfs/inode.c| 108 ++-- > fs/btrfs/ioctl.c| 57 +++--- > fs/btrfs/ordered-data.c | 48 +++--- > fs/btrfs/ordered-data.h |6 +- > fs/btrfs/print-tree.c |2 +- > fs/btrfs/relocation.c | 40 +++-- > fs/btrfs/scrub.c| 68 +++- > fs/btrfs/super.c| 34 ++-- > fs/btrfs/transaction.c | 183 ++-- > fs/btrfs/transaction.h | 12 +- > fs/btrfs/tree-defrag.c |2 +- > fs/btrfs/tree-log.c | 40 +++-- > fs/btrfs/volumes.c | 246 +- > fs/btrfs/volumes.h | 10 +- > 25 files changed, 912 insertions(+), 889 deletions(-) > -- 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
[PATCH v1 2/3] btrfs: pass fs_info to btrfs_test_opt instead of root
btrfs_test_opt only needs fs_info from the root passed. So just pass the fs_info directly. Signed-off-by: Arne Jansen --- fs/btrfs/ctree.h|2 +- fs/btrfs/disk-io.c |8 +++--- fs/btrfs/extent-tree.c | 55 ++- fs/btrfs/file.c |2 +- fs/btrfs/free-space-cache.c |2 +- fs/btrfs/inode.c| 10 fs/btrfs/ioctl.c|2 +- fs/btrfs/super.c| 30 +++--- fs/btrfs/transaction.c |5 ++- fs/btrfs/tree-defrag.c |2 +- fs/btrfs/tree-log.c |2 +- fs/btrfs/volumes.c |9 --- 12 files changed, 66 insertions(+), 63 deletions(-) diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index b51a06c..b2fdcca 100644 --- a/fs/btrfs/ctree.h +++ b/fs/btrfs/ctree.h @@ -1343,7 +1343,7 @@ struct btrfs_ioctl_defrag_range_args { #define btrfs_clear_opt(o, opt)((o) &= ~BTRFS_MOUNT_##opt) #define btrfs_set_opt(o, opt) ((o) |= BTRFS_MOUNT_##opt) -#define btrfs_test_opt(root, opt) ((root)->fs_info->mount_opt & \ +#define btrfs_test_opt(fs_info, opt) ((fs_info)->mount_opt & \ BTRFS_MOUNT_##opt) /* * Inode flags diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index c67a1e6..4d28eaf 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -1990,8 +1990,8 @@ struct btrfs_root *open_ctree(struct super_block *sb, if (IS_ERR(fs_info->transaction_kthread)) goto fail_cleaner; - if (!btrfs_test_opt(tree_root, SSD) && - !btrfs_test_opt(tree_root, NOSSD) && + if (!btrfs_test_opt(fs_info, SSD) && + !btrfs_test_opt(fs_info, NOSSD) && !fs_info->fs_devices->rotating) { printk(KERN_INFO "Btrfs detected SSD devices, enabling SSD " "mode\n"); @@ -2304,7 +2304,7 @@ int write_all_supers(struct btrfs_root *root, int max_mirrors) u64 flags; max_errors = btrfs_super_num_devices(&root->fs_info->super_copy) - 1; - do_barriers = !btrfs_test_opt(root, NOBARRIER); + do_barriers = !btrfs_test_opt(root->fs_info, NOBARRIER); sb = &root->fs_info->super_for_commit; dev_item = &sb->dev_item; @@ -3002,7 +3002,7 @@ static int btrfs_destroy_pinned_extent(struct btrfs_root *root, break; /* opt_discard */ - if (btrfs_test_opt(root, DISCARD)) + if (btrfs_test_opt(root->fs_info, DISCARD)) ret = btrfs_error_discard_extent(root, start, end + 1 - start, NULL); diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 2236c77..27cc348 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -4298,7 +4298,7 @@ int btrfs_finish_extent_commit(struct btrfs_trans_handle *trans, if (ret) break; - if (btrfs_test_opt(root, DISCARD)) + if (btrfs_test_opt(fs_info, DISCARD)) ret = btrfs_discard_extent(root, start, end + 1 - start, NULL); @@ -4811,7 +4811,8 @@ static noinline int find_free_extent(struct btrfs_trans_handle *trans, int data) { int ret = 0; - struct btrfs_root *root = orig_root->fs_info->extent_root; + struct btrfs_fs_info *fs_info = orig_root->fs_info; + struct btrfs_root *root = fs_info->extent_root; struct btrfs_free_cluster *last_ptr = NULL; struct btrfs_block_group_cache *block_group = NULL; int empty_cluster = 2 * 1024 * 1024; @@ -4833,7 +4834,7 @@ static noinline int find_free_extent(struct btrfs_trans_handle *trans, ins->objectid = 0; ins->offset = 0; - space_info = __find_space_info(root->fs_info, data); + space_info = __find_space_info(fs_info, data); if (!space_info) { printk(KERN_ERR "No space info for %d\n", data); return -ENOSPC; @@ -4850,14 +4851,14 @@ static noinline int find_free_extent(struct btrfs_trans_handle *trans, allowed_chunk_alloc = 1; if (data & BTRFS_BLOCK_GROUP_METADATA && use_cluster) { - last_ptr = &root->fs_info->meta_alloc_cluster; - if (!btrfs_test_opt(root, SSD)) + last_ptr = &fs_info->meta_alloc_cluster; + if (!btrfs_test_opt(fs_info, SSD)) empty_cluster = 64 * 1024; } if ((data & BTRFS_BLOCK_GROUP_DATA) && use_cluster && - btrfs_test_opt(root, SSD)) { - last_ptr = &root->fs_info->data_alloc_cluster; + btrfs_test_opt(fs_info, SSD)) { + last_ptr = &fs_info->data_alloc_cluster; } if (last_ptr) { @@
[PATCH v1 1/3] btrfs: remove struct btrfs_root parameter where unused
The following functions had a struct btrfs_root * parameter which went unused: btrfs_set_block_group_rw btrfs_destroy_delayed_refs btrfs_csum_data extent_data_ref_count copy_to_sk Signed-off-by: Arne Jansen --- fs/btrfs/compression.c |3 +-- fs/btrfs/ctree.c| 20 ++-- fs/btrfs/ctree.h|5 + fs/btrfs/disk-io.c | 14 ++ fs/btrfs/disk-io.h |2 +- fs/btrfs/extent-tree.c | 16 ++-- fs/btrfs/file-item.c|3 +-- fs/btrfs/free-space-cache.c |6 +++--- fs/btrfs/inode.c|7 +++ fs/btrfs/ioctl.c|5 ++--- fs/btrfs/relocation.c |2 +- fs/btrfs/scrub.c|7 +++ 12 files changed, 38 insertions(+), 52 deletions(-) diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c index bfe42b0..2182cc5 100644 --- a/fs/btrfs/compression.c +++ b/fs/btrfs/compression.c @@ -105,7 +105,6 @@ static int check_compressed_csum(struct inode *inode, u64 disk_start) { int ret; - struct btrfs_root *root = BTRFS_I(inode)->root; struct page *page; unsigned long i; char *kaddr; @@ -120,7 +119,7 @@ static int check_compressed_csum(struct inode *inode, csum = ~(u32)0; kaddr = kmap_atomic(page, KM_USER0); - csum = btrfs_csum_data(root, kaddr, csum, PAGE_CACHE_SIZE); + csum = btrfs_csum_data(kaddr, csum, PAGE_CACHE_SIZE); btrfs_csum_final(csum, (char *)&csum); kunmap_atomic(kaddr, KM_USER0); diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c index b0e18d9..670bed7 100644 --- a/fs/btrfs/ctree.c +++ b/fs/btrfs/ctree.c @@ -339,7 +339,7 @@ static noinline int update_ref_for_cow(struct btrfs_trans_handle *trans, BUG_ON(ret); } if (new_flags != 0) { - ret = btrfs_set_disk_extent_flags(trans, root, + ret = btrfs_set_disk_extent_flags(trans, buf->start, buf->len, new_flags, 0); @@ -1763,7 +1763,7 @@ done: * fixing up the blocks in ram so the tree is consistent. */ static int fixup_low_keys(struct btrfs_trans_handle *trans, - struct btrfs_root *root, struct btrfs_path *path, + struct btrfs_path *path, struct btrfs_disk_key *key, int level) { int i; @@ -1814,7 +1814,7 @@ int btrfs_set_item_key_safe(struct btrfs_trans_handle *trans, btrfs_set_item_key(eb, &disk_key, slot); btrfs_mark_buffer_dirty(eb); if (slot == 0) - fixup_low_keys(trans, root, path, &disk_key, 1); + fixup_low_keys(trans, path, &disk_key, 1); return 0; } @@ -2579,7 +2579,7 @@ static noinline int __push_leaf_left(struct btrfs_trans_handle *trans, clean_tree_block(trans, root, right); btrfs_item_key(right, &disk_key, 0); - wret = fixup_low_keys(trans, root, path, &disk_key, 1); + wret = fixup_low_keys(trans, path, &disk_key, 1); if (wret) ret = wret; @@ -2966,7 +2966,7 @@ again: path->nodes[0] = right; path->slots[0] = 0; if (path->slots[1] == 0) { - wret = fixup_low_keys(trans, root, + wret = fixup_low_keys(trans, path, &disk_key, 1); if (wret) ret = wret; @@ -3301,7 +3301,7 @@ int btrfs_truncate_item(struct btrfs_trans_handle *trans, btrfs_set_disk_key_offset(&disk_key, offset + size_diff); btrfs_set_item_key(leaf, &disk_key, slot); if (slot == 0) - fixup_low_keys(trans, root, path, &disk_key, 1); + fixup_low_keys(trans, path, &disk_key, 1); } item = btrfs_item_nr(leaf, slot); @@ -3532,7 +3532,7 @@ int btrfs_insert_some_items(struct btrfs_trans_handle *trans, ret = 0; if (slot == 0) { btrfs_cpu_key_to_disk(&disk_key, cpu_key); - ret = fixup_low_keys(trans, root, path, &disk_key, 1); + ret = fixup_low_keys(trans, path, &disk_key, 1); } if (btrfs_leaf_free_space(root, leaf) < 0) { @@ -3638,7 +3638,7 @@ int setup_items_for_insert(struct btrfs_trans_handle *trans, ret = 0; if (slot == 0) { btrfs_cpu_key_to_disk(&disk_key, cpu_key); - ret = fixup_low_keys(trans, root, path, &disk_key, 1); + ret = fixup_low_keys(trans, path, &disk_key, 1); } btrfs_unl
[PATCH v1 0/3] btrfs: cleanup: pass fs_info instead of root where possible
This series aims to clean up passing of struct btrfs_root and struct btrfs_fs_info. It first removes the root pointer from functions and macros where it's not needed, afterwards it passes fs_info instead of root to functions which only need root->fs_info. It is based on 3.0-rc1. These patches are based on the following two Coccinelle-scripts, but also involve some hand editing. a) Remove root parameter where it's completely unneeded. Fix up callers. @r@ identifier fn != btrfs_inc_extent_ref; identifier root; parameter list[n] P; @@ fn(P -, struct btrfs_root *root ,...) { ... when != root } @@ identifier r.fn; expression list[r.n] E; identifier x; @@ fn(E -,x ,...) b) Change root parameter to fs_info where only root->fs_info is needed. Fix up callers. @ s exists @ identifier fn; identifier root, sf; identifier member != fs_info; position p; expression E; parameter list[n] P; @@ fn@p(P,struct btrfs_root *root,...) { ... ( root->member | sf(...,root,...) | (root && ...) | (root == ...) | E = root ) ... when any } @ t @ identifier fn != {process_one_buffer,btrfs_inc_extent_ref,btrfs_free_extent}; identifier root; parameter list[n] P; position p != s.p; @@ fn@p(P, -struct btrfs_root *root +struct btrfs_fs_info *fs_info ,...) { <... - root->fs_info + fs_info ...> } @@ identifier t.fn; expression list[t.n] E; expression x; @@ fn(E, -x +x->fs_info ,...) @@ function fn; identifier fs_info; identifier x; parameter list[n] P; @@ fn(P, struct btrfs_fs_info *fs_info, ... ) { ... - struct btrfs_fs_info *x = fs_info; <... - x + fs_info ...> } Thanks to Julia Lawall for helping to build the scripts. Arne Jansen (3): btrfs: remove struct btrfs_root parameter where unused btrfs: pass fs_info to btrfs_test_opt instead of root btrfs: cleanup: pass fs_info instead of root where possible fs/btrfs/compression.c | 11 +- fs/btrfs/ctree.c| 76 + fs/btrfs/ctree.h| 66 fs/btrfs/delayed-inode.c| 43 +++--- fs/btrfs/disk-io.c | 281 +++--- fs/btrfs/disk-io.h | 24 ++-- fs/btrfs/extent-tree.c | 409 ++- fs/btrfs/file-item.c|5 +- fs/btrfs/file.c | 16 +- fs/btrfs/free-space-cache.c | 12 +- fs/btrfs/free-space-cache.h |2 +- fs/btrfs/inode.c| 108 ++-- fs/btrfs/ioctl.c| 57 +++--- fs/btrfs/ordered-data.c | 48 +++--- fs/btrfs/ordered-data.h |6 +- fs/btrfs/print-tree.c |2 +- fs/btrfs/relocation.c | 40 +++-- fs/btrfs/scrub.c| 68 +++- fs/btrfs/super.c| 34 ++-- fs/btrfs/transaction.c | 183 ++-- fs/btrfs/transaction.h | 12 +- fs/btrfs/tree-defrag.c |2 +- fs/btrfs/tree-log.c | 40 +++-- fs/btrfs/volumes.c | 246 +- fs/btrfs/volumes.h | 10 +- 25 files changed, 912 insertions(+), 889 deletions(-) -- 1.7.3.4 -- 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: strange btrfs sub list output
2011-05-27 13:49:52 +0200, Andreas Philipp: [...] > > Thanks, I can understand that. What I don't get is how one creates > > a subvol with a top-level other than 5. I might be missing the > > obvious, though. > > > > If I do: > > > > btrfs sub create A btrfs sub create A/B btrfs sub snap A A/B/C > > > > A, A/B, A/B/C have their top-level being 5. How would I get a new > > snapshot to be a child of A/B for instance? > > > > In my case, 285, was not appearing in the btrfs sub list output, > > 287 was a child of 285 with path "data" while all I did was create > > a snapshot of 284 (path u6:10022/vm+xfs@u8/xvda1/g8/v3/data in vol > > 5) in u6:10022/vm+xfs@u8/xvda1/g8/v3/snapshots/2011-03-30 > > > > So I did manage to get a volume with a parent other than 5, but I > > did not ask for it. [...] > Reconsidering the explanations on btrfs subvolume list in this thread > I get the impression that a line in the output of btrfs subvolume list > with top level other than 5 indicates that the backrefs from one > subvolume to its parent are broken. > > What's your opinion on this? [...] Given that I don't really get what the parent-child relationship means in that context, I can't really comment. In effect, the snapshot had been created and was attached to the right directory (but didn't appear in the sub list), and there was an additional "data" volume that I had not asked for nor created that had the snapshot above as parent and that did appear in the sub list. It pretty much looks like a bug to me, I'd like to understand more so that I can maybe try and avoid running into it again. -- Stephane -- 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: Damaged super block / fs root
Hello Chris On 30.05.2011 21:03, Chris Mason wrote: How big is the FS? About 100 G on a 500 G partition. I would only like to recover some plain text files from it (source code), I don't need the partition to be mountable again. What command did you use to overwrite the super block? Please try to tell us exactly which commands were run. I had to install FreeBSD on that disk (with Linux, a btrfs partition, and several free partitions on it). When using the FreeBSD partition tool, I didn't create or delete any partitions. I only assigned a free partition to FreeBSD. When I booted later in Linux the Btrfs partition did not mount anymore. There are other ways we can try to pull things off, but you should try btrfsck -s 2 as well. btrfcsk -s 2 exits with: using SB copy 2, bytenr 274877906944 No valid Btrfs found on /dev/sda10 -- 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: WARNING: at fs/btrfs/extent-tree.c:5695 btrfs_alloc_free_block+0x22c/0x370 [btrfs]()
Am 31.05.2011 10:18, schrieb Chris Mason: > Excerpts from Sascha Biermanns's message of 2011-05-31 04:12:58 -0400: >> Yesterday, I compiled the new kernel 3.0rc1 from git, but I never >> successed to go over the point: "Removing old temporary files". >> Pressing control-c let me boot on, but the pc was the complete time on >> very high load. It took me minutes, just to reach the tty login - and >> again minutes after login in, that I had my shell and a prompt to enter >> something. The load was at that time beyond 10. >> >> Now in my /var/log/messages, I found the following warning - and because >> it happens when "removing" temporary/old files, that might be why the >> computer has so much trouble: >> > >> May 30 23:25:17 localhost kernel: [17117.213589] Call Trace: > > Do you have the very first full oops? This has the call trace, but not > the beginning text that describes why we've crashed. > > -chris Hi Chris, the log starts here - before May 30 21:40:52 there is for 6 hours nothing. It's the beginning of the logging. I'm sorry to say so, but I'm absolutely unable to boot into 3.0rc1 I used a complete with luks encrypted btrfs partition, there is only another /boot partition with ext4 - and this system is running since march 2010. On other kernels (2.6.38 or 2.6.39) - the logging starts much more early - but like I said - the load was unbelieveable high the whole time, the hard disks reached maximum temperature (so it was very hard to lay the hands on the computer) - and my only explanation are these entries. May 30 21:40:52 localhost -- MARK -- May 30 21:41:22 localhost Tor[1422]: We tried for 15 seconds to connect to '[scrubbed]' using exit 'Amunet8'. Retrying on a new circuit. May 30 21:41:37 localhost Tor[1422]: We tried for 15 seconds to connect to '[scrubbed]' using exit 'Wallnut'. Retrying on a new circuit. May 30 21:41:52 localhost Tor[1422]: We tried for 15 seconds to connect to '[scrubbed]' using exit 'Amunet6'. Retrying on a new circuit. May 30 21:42:07 localhost Tor[1422]: We tried for 15 seconds to connect to '[scrubbed]' using exit 'politkovskaja'. Retrying on a new circuit. May 30 21:42:22 localhost Tor[1422]: We tried for 15 seconds to connect to '[scrubbed]' using exit 'BostonUCompSci'. Retrying on a new circuit. May 30 21:42:37 localhost Tor[1422]: We tried for 15 seconds to connect to '[scrubbed]' using exit 'rainbowwarrior'. Retrying on a new circuit. May 30 21:42:52 localhost Tor[1422]: We tried for 15 seconds to connect to '[scrubbed]' using exit 'ada'. Retrying on a new circuit. May 30 21:42:52 localhost Tor[1422]: Tried for 125 seconds to get a connection to [scrubbed]:80. Giving up. May 30 21:51:10 localhost kernel: [11470.581905] [ cut here ] May 30 21:51:10 localhost kernel: [11470.581965] WARNING: at fs/btrfs/extent-tree.c:5695 btrfs_alloc_free_block+0x22c/0x370 [btrfs]() May 30 21:51:10 localhost kernel: [11470.581972] Hardware name: Presario CQ56 Notebook PC May 30 21:51:10 localhost kernel: [11470.581976] Modules linked in: cryptd aes_x86_64 aes_generic ipt_REJECT ipt_LOG xt_limit xt_tcpudp ipt_addrtype xt_state ip6table_filter ip6_tables nf_nat_irc nf_conntrack_irc nf_nat_ftp nf _nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables ipv6 fuse cpufreq_conservative cpufreq_powersave cpufreq_ondemand fglrx(P) snd_hda_codec_realtek powernow_k8 freq_table mper f snd_hda_intel snd_hda_codec radeon ttm snd_pcm_oss snd_hwdep joydev snd_pcm drm_kms_helper drm uvcvideo hp_wmi snd_mixer_oss snd_timer i2c_algo_bit videodev snd i2c_piix4 soundcore v4l2_compat_ioctl32 sparse_keymap wmi arc4 edac_core evdev snd_page_alloc ecb sp5100_tco battery shpchp processor sg edac_mce_amd psmouse i2c_core video thermal k10temp pci_hotplug pcspkr serio_raw button ac brcm80211(C) mac80211 cfg80211 rfkill r8169 mii uvesafb cn sh a256_generic twofish_generic twofish_x86_64 twofish_common cbc usbhid hid dm_crypt dm_mod btrfs zlib_deflate crc32c libcrc32c ext4 mbcache jbd2 crc16 ohci_hcd ehci_hcd sr_mod cdrom usbcore sd_mod ahci libahci libata scsi_mod -- 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: WARNING: at fs/btrfs/extent-tree.c:5695 btrfs_alloc_free_block+0x22c/0x370 [btrfs]()
Excerpts from Sascha Biermanns's message of 2011-05-31 04:12:58 -0400: > Yesterday, I compiled the new kernel 3.0rc1 from git, but I never > successed to go over the point: "Removing old temporary files". > Pressing control-c let me boot on, but the pc was the complete time on > very high load. It took me minutes, just to reach the tty login - and > again minutes after login in, that I had my shell and a prompt to enter > something. The load was at that time beyond 10. > > Now in my /var/log/messages, I found the following warning - and because > it happens when "removing" temporary/old files, that might be why the > computer has so much trouble: > > May 30 23:25:17 localhost kernel: [17117.213589] Call Trace: Do you have the very first full oops? This has the call trace, but not the beginning text that describes why we've crashed. -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
WARNING: at fs/btrfs/extent-tree.c:5695 btrfs_alloc_free_block+0x22c/0x370 [btrfs]()
Yesterday, I compiled the new kernel 3.0rc1 from git, but I never successed to go over the point: "Removing old temporary files". Pressing control-c let me boot on, but the pc was the complete time on very high load. It took me minutes, just to reach the tty login - and again minutes after login in, that I had my shell and a prompt to enter something. The load was at that time beyond 10. Now in my /var/log/messages, I found the following warning - and because it happens when "removing" temporary/old files, that might be why the computer has so much trouble: May 30 23:25:17 localhost kernel: [17117.213589] Call Trace: May 30 23:25:17 localhost kernel: [17117.213598] [] ? warn_slowpath_common+0x7b/0xc0 May 30 23:25:17 localhost kernel: [17117.213625] [] ? btrfs_alloc_free_block+0x22c/0x370 [btrfs] May 30 23:25:17 localhost kernel: [17117.213636] [] ? schedule+0x53c/0xd70 May 30 23:25:17 localhost kernel: [17117.213643] [] ? schedule+0x5ac/0xd70 May 30 23:25:17 localhost kernel: [17117.213672] [] ? read_extent_buffer+0xcf/0x1e0 [btrfs] May 30 23:25:17 localhost kernel: [17117.213698] [] ? __btrfs_cow_block+0x163/0x8d0 [btrfs] May 30 23:25:17 localhost kernel: [17117.213727] [] ? btrfs_buffer_uptodate+0x49/0x70 [btrfs] May 30 23:25:17 localhost kernel: [17117.213753] [] ? btrfs_cow_block+0x119/0x2b0 [btrfs] May 30 23:25:17 localhost kernel: [17117.213778] [] ? btrfs_search_slot+0x1dc/0x9b0 [btrfs] May 30 23:25:17 localhost kernel: [17117.213807] [] ? btrfs_lookup_file_extent+0x33/0x40 [btrfs] May 30 23:25:17 localhost kernel: [17117.213837] [] ? btrfs_drop_extents+0xc0/0x960 [btrfs] May 30 23:25:17 localhost kernel: [17117.213847] [] ? __switch_to+0xc5/0x300 May 30 23:25:17 localhost kernel: [17117.213854] [] ? rb_insert_color+0x101/0x140 May 30 23:25:17 localhost kernel: [17117.213863] [] ? kmem_cache_alloc+0x15c/0x180 May 30 23:25:17 localhost kernel: [17117.213894] [] ? insert_reserved_file_extent.constprop.48+0x69/0x230 [btrfs] May 30 23:25:17 localhost kernel: [17117.213926] [] ? btrfs_finish_ordered_io+0x2f2/0x330 [btrfs] May 30 23:25:17 localhost kernel: [17117.213935] [] ? del_timer_sync+0x2a/0x50 May 30 23:25:17 localhost kernel: [17117.213965] [] ? end_bio_extent_writepage+0x122/0x160 [btrfs] May 30 23:25:17 localhost kernel: [17117.213994] [] ? end_workqueue_fn+0x39/0x120 [btrfs] May 30 23:25:17 localhost kernel: [17117.214020] [] ? worker_loop+0x14e/0x4e0 [btrfs] May 30 23:25:17 localhost kernel: [17117.214047] [] ? worker_loop+0x0/0x4e0 [btrfs] May 30 23:25:17 localhost kernel: [17117.214054] [] ? kthread+0x7e/0x90 May 30 23:25:17 localhost kernel: [17117.214061] [] ? kernel_thread_helper+0x4/0x10 May 30 23:25:17 localhost kernel: [17117.214068] [] ? kthread+0x0/0x90 May 30 23:25:17 localhost kernel: [17117.214075] [] ? kernel_thread_helper+0x0/0x10 May 30 23:25:17 localhost kernel: [17117.214080] ---[ end trace 6e2121230335769a ]--- May 30 23:25:17 localhost kernel: [17117.214109] [ cut here ] May 30 23:25:17 localhost kernel: [17117.214135] WARNING: at fs/btrfs/extent-tree.c:5695 btrfs_alloc_free_block+0x22c/0x370 [btrfs]() May 30 23:25:17 localhost kernel: [17117.214140] Hardware name: Presario CQ56 Notebook PC -- 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
btrfs hang on brd
Hi I seem to be able to get btrfs reproducibly to produce warnings and finally hang when running a stress test on a ramdisk. Testing was done using the "integration-test" branch of btrfs-unstable. Note that I also tested v2.6.39 and "integration-test" took much longer to hang i.e. it is an improvement The test script and stack dumps are below. Is this a valid test? Is it worth me investigating these? Regards Adrian Test #!/bin/sh sudo modprobe brd rd_size=262144 sudo umount /mnt/test/ 2> /dev/null echo 'mkfs.btrfs /dev/ram0' sudo mkfs.btrfs /dev/ram0 sudo mkdir -p /mnt/test echo 'mount -t btrfs /dev/ram0 /mnt/test' sudo mount -t btrfs /dev/ram0 /mnt/test sudo mkdir -p /mnt/test/test sudo chown $USER /mnt/test/test sudo chgrp $USER /mnt/test/test sudo umount /mnt/test full=0 i=0 while true; do sudo mount -t btrfs /dev/ram0 /mnt/test if df | grep ram0 | grep 100% > /dev/null; then full=`expr $full \+ 1` if test $full -gt 6;then rm -rf /mnt/test/test/* full=0 fi else full=0 fi fsstress -c -r -d /mnt/test/test -p 3 -n 1000 -l 10 sudo umount /mnt/test i=`expr $i \+ 1` echo $i done Stack dumps for warnings [ 7481.520750] WARNING: at fs/btrfs/extent-tree.c:5648 btrfs_alloc_free_block+0x14e/0x357 [btrfs]() [ 7481.520753] Hardware name: XPS 8300 [ 7481.520754] Modules linked in: tcp_lp tun btrfs zlib_deflate libcrc32c brd fuse cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec broadcom tg3 snd_hwdep snd_seq snd_seq_device snd_pcm joydev pcspkr iTCO_wdt iTCO_vendor_support dcdbas serio_raw i2c_i801 snd_timer snd microcode soundcore snd_page_alloc usb_storage i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] [ 7481.520805] Pid: 3980, comm: btrfs-endio-wri Not tainted 2.6.39-integration-test-20110526-01+ #2 [ 7481.520808] Call Trace: [ 7481.520818] [] warn_slowpath_common+0x85/0x9d [ 7481.520824] [] warn_slowpath_null+0x1a/0x1c [ 7481.520838] [] btrfs_alloc_free_block+0x14e/0x357 [btrfs] [ 7481.520865] [] ? map_private_extent_buffer+0xb1/0xd5 [btrfs] [ 7481.520875] [] __btrfs_cow_block+0x102/0x31e [btrfs] [ 7481.520883] [] ? btrfs_set_item_key+0x3/0x20 [btrfs] [ 7481.520892] [] btrfs_cow_block+0x104/0x14d [btrfs] [ 7481.520910] [] btrfs_search_slot+0x162/0x502 [btrfs] [ 7481.520925] [] btrfs_lookup_file_extent+0x3c/0x3e [btrfs] [ 7481.520936] [] ? btrfs_alloc_path+0x1a/0x2b [btrfs] [ 7481.520955] [] btrfs_drop_extents+0x10e/0x731 [btrfs] [ 7481.520960] [] ? need_resched+0x23/0x2d [ 7481.520966] [] ? _cond_resched+0xe/0x22 [ 7481.520972] [] ? slab_pre_alloc_hook.clone.32+0x2d/0x31 [ 7481.520977] [] ? kmem_cache_alloc+0x29/0xf7 [ 7481.521002] [] insert_reserved_file_extent.clone.34+0x70/0x1fc [btrfs] [ 7481.521027] [] ? lock_extent_bits+0x5e/0xa8 [btrfs] [ 7481.521044] [] btrfs_endio_direct_write+0x171/0x29a [btrfs] [ 7481.521060] [] ? end_workqueue_fn+0xf6/0x10e [btrfs] [ 7481.521065] [] bio_endio+0x2d/0x2f [ 7481.521087] [] end_workqueue_fn+0x101/0x10e [btrfs] [ 7481.521101] [] worker_loop+0x193/0x4ca [btrfs] [ 7481.521116] [] ? btrfs_queue_worker+0x214/0x214 [btrfs] [ 7481.521119] [] kthread+0x82/0x8a [ 7481.521124] [] kernel_thread_helper+0x4/0x10 [ 7481.521136] [] ? kthread_worker_fn+0x14b/0x14b [ 7481.521141] [] ? gs_change+0x13/0x13 [ 7481.521144] ---[ end trace abb147a5624a0a24 ]--- [ 7481.521161] [ cut here ] [ 7481.521176] WARNING: at fs/btrfs/extent-tree.c:5648 btrfs_alloc_free_block+0x14e/0x357 [btrfs]() [ 7481.521178] Hardware name: XPS 8300 [ 7481.521180] Modules linked in: tcp_lp tun btrfs zlib_deflate libcrc32c brd fuse cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec broadcom tg3 snd_hwdep snd_seq snd_seq_device snd_pcm joydev pcspkr iTCO_wdt iTCO_vendor_support dcdbas serio_raw i2c_i801 snd_timer snd microcode soundcore snd_page_alloc usb_storage i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] [ 7481.521237] Pid: 3980, comm: btrfs-endio-wri Tainted: GW 2.6.39-integration-test-20110526-01+ #2 [ 7481.521240] Call Trace: [ 7481.521245] [] warn_slowpath_common+0x85/0x9d [ 7481.521250] [] warn_slowpath_null+0x1a/0x1c [ 7481.521288] [] btrfs_alloc_free_block+0x14e/0x357 [btrfs] [ 7481.521303] [] ? map_private_extent_buffer+0xb1/0xd5 [btrfs] [ 7481.521313] [] __btrfs_cow_block+0x102/0x31e [btrfs] [ 7481.521322] [] ? btrfs_set_item_key+0x3/0x20 [btrfs] [ 7481.521341] [] btrfs_cow_block+0x104/0x14d [btrfs] [ 74