[PATCH] Remove unnecessary condition check
extent_io.c:__extent_writepage_io has this code:
if (!compressed)
...
else if (compressed)
Signed-off-by: Diego Calleja
---
fs/btrfs/extent_io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 1ff438fd5bc2..a53fb7b8a262 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -3498,7 +3498,7 @@ static noinline_for_stack int
__extent_writepage_io(struct inode *inode,
btrfs_writepage_endio_finish_ordered(page, cur,
cur + iosize - 1,
1);
- else if (compressed) {
+ else {
/* we don't want to end_page_writeback on
* a compressed extent. this happens
* elsewhere
--
2.22.0
Re: [PATCH] btrfs: extent-tree: Add comment for walk_control to explain how btrfs drops a subvolume.
El martes, 23 de julio de 2019 9:57:21 (CEST) Qu Wenruo escribió: > + * A <- tree root, level 2 > + * / \ > + * B C<- tree nodes, level 1 > + */ \ / \ > + *D E F G <- tree leaves, level 0 > + * > + * 1) Basic dropping. > + *All above tree blocks are owned exclusively. > + *Drop tree blocks using LRN iteration. > + *Tree drop sequence is: D E B F C G A. Excuse me if I am wrong, but there seems to be a small typo, shouldn't it be "F G C"?
Re: [PATCH 00/17] Add support for SHA-256 checksums
El miércoles, 15 de mayo de 2019 19:27:21 (CEST) David Sterba escribió: > Once the code is ready for more checksum algos, we'll pick candidates > and my idea is to select 1 fast (not necessarily strong, but better > than crc32c) and 1 strong (but slow, and sha256 is the candidate at the > moment) Modern CPUs have SHA256 instructions, it is actually that slow? (not sure how fast these instructions are) If btrfs needs an algorithm with good performance/security ratio, I would suggest considering BLAKE2 [1]. It is based in the BLAKE algorithm that made to the final round in the SHA3 competition, it is considered pretty secure (above SHA2 at least), and it was designed to take advantage of modern CPU features and be as fast as possible - it even beats SHA1 in that regard. It is not currently in the kernel but Wireguard uses it and will add an implementation when it's merged (but Wireguard doesn't use the crypto layer for some reason...)
Re: [PATCH v5 4/6] Btrfs: heuristic add detection of zeroed sample
El miércoles, 23 de agosto de 2017 2:26:48 (CEST) Timofey Titovets escribió:
> + for (i = 0; i < workspace->sample_size; i += sizeof(zero)) {
> + if (memcmp(&workspace->sample[i], &zero, sizeof(zero)))
> + return false;
Instead of just checking for 0, wouldn't it be a better idea to check
for any kind of repetitions?
As in, iterate over the sample and memcmp() each part of sample with
the previous one. The cost would be the same, and it would detect not
just zeros, but any kind of repeated data. Is there any reason I'm
missing for not doing this?
--
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: Input/output error, nothing appended in dmesg
El sábado, 6 de agosto de 2016 0:45:13 (CEST) Tomasz Chmielewski escribió: > And, miracle cure O_o > > # file ./2016-08-02/serverX/syslog.log > ERROR: cannot read `./2016-08-02/serverX/syslog.log' (Input/output > error) > > # echo 3 > /proc/sys/vm/drop_caches > > # file 2016-08-02/serverX/syslog.log > 2016-08-02/serverX/syslog.log: ASCII text, with very long lines FWIW, bugs similar to this one were reported in the past: http://www.spinics.net/lists/linux-btrfs/msg54962.html http://www.spinics.net/lists/linux-btrfs/msg52371.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
Re: Input/output error on newly created file
El jueves, 12 de mayo de 2016 8:46:00 (CEST) Nikolaus Rath escribió: > *ping* > > Anyone any idea? All I can say is that I've had the same problem in the past. In my case, the problematic files where active torrents. The interesting thing is that I was able to read them correctly up to a point, then I would get the same error as you. No messages in dmesg. The amount of data I was able to read from them was not random, it was something multiple of 4K. After reboot the problems went away and I wasn't able to reproduce it. There has been reports of similiar issues in the past: http://www.spinics.net/lists/linux-btrfs/msg52371.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
Re: [PATCH 0/5] [RFC] RAID-level terminology change
El Domingo, 10 de marzo de 2013 12:23:56 Martin Steigerwald escribió: > Any other idea to make it less cryptic? I would vote for optionally allowing to expand the codes into something more verbose and self-documented, ie: 1CmS1P <-> 1Copy-manyStripes-1Parity -- 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 v2] Btrfs-progs: add support for device replace procedure
El Martes, 11 de diciembre de 2012 17:50:00 Stefan Behrens escribió: > This is the user mode part of the device replace patch series. > > The command group "btrfs replace" is added with three commands: > - btrfs replace start srcdev|srcdevid targetdev [-Bfr] mount_point > - btrfs replace status mount_point [-1] > - btrfs replace cancel mount_point Wouldn't this be better placed under the "btrfs device" command group? -- 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 progs: quota groups support
On Viernes, 10 de agosto de 2012 15:51:07 Jan Schmidt escribió: > From: Arne Jansen > > Signed-off-by: Jan Schmidt > Signed-off-by: Arne Jansen > --- > This is the rebased version of Arne's qgroup patch set. He's the > original author, which is why I'm sending with his author tag. A small suggestion, it would be nice to have a man page update. -- 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: [systemd-devel] systemd-udevd: excessive I/O usage
[resend, for some reason kmail formatted the previous message with html] On Martes, 5 de junio de 2012 09:50:56 Alexander E. Patrakov escribió: > Result: boot from ext4 takes less than 15 seconds, while boot from > btrfs takes 9 minutes (or 5 minutes if I disable readahead - the data > file is not valid anyway on btrfs). I also had this problem. It turns out that btrfs was creating the space cache from scratch (which takes several minutes) on each boot, for some reason. I added the space_cache mount option to fstab, and now my system boots fast. I suggest trying it. -- 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: Honest timeline for btrfsck
On Viernes, 7 de Octubre de 2011 21:10:33 Asdo escribió: > failures, but you can always mount by rolling back to a previous > uberblock, showing an earlier view of the filesystem, which would be > consistent. This is already available in Btrfs, command btrfsck -s. -- 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: fix memory leak in btrfs_defrag_file
kmemleak found this:
unreferenced object 0x8801b64af968 (size 512):
comm "btrfs-cleaner", pid 3317, jiffies 4306810886 (age 903.272s)
hex dump (first 32 bytes):
00 82 01 07 00 ea ff ff c0 83 01 07 00 ea ff ff
80 82 01 07 00 ea ff ff c0 87 01 07 00 ea ff ff
backtrace:
[] kmemleak_alloc+0x5c/0xc0
[] kmem_cache_alloc_trace+0x163/0x240
[] btrfs_defrag_file+0xf0/0xb20
[] btrfs_run_defrag_inodes+0x165/0x210
[] cleaner_kthread+0x177/0x190
[] kthread+0x8d/0xa0
[] kernel_thread_helper+0x4/0x10
[] 0x
"pages" is not always freed. Fix it removing the unnecesary additional return.
Signed-off-by: Diego Calleja
---
fs/btrfs/ioctl.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Index: linux/fs/btrfs/ioctl.c
===
--- linux.orig/fs/btrfs/ioctl.c
+++ linux/fs/btrfs/ioctl.c
@@ -1130,17 +1130,15 @@ int btrfs_defrag_file(struct inode *inod
disk_super = &root->fs_info->super_copy;
features = btrfs_super_incompat_flags(disk_super);
if (range->compress_type == BTRFS_COMPRESS_LZO) {
features |= BTRFS_FEATURE_INCOMPAT_COMPRESS_LZO;
btrfs_set_super_incompat_flags(disk_super, features);
}
- if (!file)
- kfree(ra);
- return defrag_count;
+ ret = defrag_count;
out_ra:
if (!file)
kfree(ra);
kfree(pages);
return ret;
}
--
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 in -rc3-00023-g14c62e7
On Sábado, 27 de Agosto de 2011 00:33:51 Diego Calleja escribió: > On Viernes, 26 de Agosto de 2011 22:59:54 Mitch Harder escribió: > > > > Do you have autodefrag enabled? > > Yes It seems that this problem has already been solved by Konstantin Khlebnikov, he posted a patch on 17 August [PATCH] btrfs: fix warning in iput for bad-inode -- 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 in -rc3-00023-g14c62e7
On Viernes, 26 de Agosto de 2011 22:59:54 Mitch Harder escribió: > > Do you have autodefrag enabled? Yes -- 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 in -rc3-00023-g14c62e7
This is what I got in my dmesg...I have lots of these warnings, didn't notice it until now. [ 235.705766] [ cut here ] [ 235.705772] WARNING: at fs/inode.c:1309 iput+0x1ed/0x210() [ 235.705773] Hardware name: [ 235.705774] Modules linked in: ipt_REJECT xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter ip_tables x_tables snd_hda_codec_hdmi snd_hda_codec_realtek wacom snd_hda_intel snd_hda_codec snd_pcm snd_timer snd soundcore e1000e i2c_i801 snd_page_alloc virtio_net virtio virtio_ring kvm_intel kvm [last unloaded: scsi_wait_scan] [ 235.705788] Pid: 3203, comm: btrfs-cleaner Not tainted 3.1.0-rc3-00023-g14c62e7 #4 [ 235.705789] Call Trace: [ 235.705794] [] warn_slowpath_common+0x7f/0xc0 [ 235.705796] [] warn_slowpath_null+0x1a/0x20 [ 235.705797] [] iput+0x1ed/0x210 [ 235.705800] [] btrfs_iget+0x1cc/0x460 [ 235.705804] [] ? _raw_spin_unlock+0x16/0x40 [ 235.705807] [] btrfs_run_defrag_inodes+0x12e/0x210 [ 235.705809] [] cleaner_kthread+0x18b/0x1a0 [ 235.705811] [] ? _raw_spin_unlock_irqrestore+0x2a/0x60 [ 235.705813] [] ? transaction_kthread+0x290/0x290 [ 235.705815] [] kthread+0x8c/0xa0 [ 235.705818] [] kernel_thread_helper+0x4/0x10 [ 235.705820] [] ? finish_task_switch+0x4e/0xe0 [ 235.705822] [] ? _raw_spin_unlock_irq+0x1c/0x40 [ 235.705824] [] ? retint_restore_args+0xe/0xe [ 235.705826] [] ? kthread_worker_fn+0x190/0x190 [ 235.705828] [] ? gs_change+0xb/0xb [ 235.705829] ---[ end trace 522a9ae26c065662 ]--- -- 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] Btrfs updates
On Lunes, 17 de Enero de 2011 22:13:01 Chris Mason escribió: > Li Zefan also added readonly snapshot support, and I'll have the > corresponding btrfs-progs changes integrated this week. I think you forgot this. -- 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: version (was: btrfs, broken design?)
On Miércoles, 26 de Enero de 2011 11:13:20 Erik Logtenberg escribió: > Diego, pls don't read anything negative in my comments, I enjoy and > respect your work very much! If you could find time to add those latest > changes to the wiki, it would be greatly appreciated. Thanks for your suggestion, I've updated the Changelog and removed the old items from the news section. 2.6.36 didn't had many btrfs changes, there was no new features. -- 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: version (was: btrfs, broken design?)
On Viernes, 21 de Enero de 2011 10:54:00 Helmut Hullen escribió: > And I never have seen somethin like "Changelog" - that would be fine > too. Check the wiki, I keep that updated: https://btrfs.wiki.kernel.org/index.php/Main_Page#News -- 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: 2.6.36-rc1 btrfs still unstable
> Even with cheap drives, a filesystem shouldn't die. With stuff like ZFS, you > can use all sorts of crap and still live with it. Btrfs should follow that > track. Sadly that's not true, a bit of cooperation of the hardware is needed. Both Btrfs and ZFS need to be sure that certain operations i.e. writting a modified superblock need to be physically on the disk. Some disks lie (or fail) when they are asked to write data to the disk, and both filesystems have faced filesystem inconsistencies due to this. AFAIK there is nothing the filesystem can do to avoid that. -- 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: 2.6.36-rc1 btrfs still unstable
On Lunes, 16 de Agosto de 2010 17:45:29 Chris Ball escribió: >Note that Btrfs does not yet have a fsck tool that can fix errors. >While Btrfs is stable on a stable machine, it is currently possible >to corrupt a filesystem irrecoverably if your machine crashes or >loses power. This will be fixed when the fsck tool is ready. But doesn't this happen only with cheap disks that don't honour barriers correctly? -- 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 v3] Btrfs: compressed file size ioctl
On Viernes, 6 de Agosto de 2010 14:21:44 Ulrich Hecht escribió: > ioctl(d, BTRFS_IOC_COMPR_SIZE, &size); I wonder...it's not possible to fit this into FIEMAP somehow? I though that FIEMAP has been designed with compressed data in mind. -- 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: [RFC PATCH 0/5] Btrfs: Add hot data tracking functionality
On Miércoles, 28 de Julio de 2010 00:00:18 bchoc...@gmail.com escribió: > With Btrfs's COW approach, an external cache (where data is moved to > SSD, rather than just cached there) makes a lot of sense. Though these As I understand it, what your proyect intends to do is to move "hot" data to a SSD which would be part of a Btrfs pool, and not do any kind of SSD caching, as bcache (http://lwn.net/Articles/394672/) does? -- 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
Poor performance with qemu
Hi, I'm using KVM, and the virtual disk (a 20 GB file using the "raw" qemu format according to virt-manager and, of course, placed on a btrfs filesystem, running the latest mainline git) is awfully slow, no matter what OS is running inside the VM. The PCBSD installer says it's copying data at a 40-50 KB/s rate. Is someone using KVM and having better numbers than me? How can I help to debug this workload? -- 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: assertion failures
On Viernes, 26 de Febrero de 2010 20:09:15 Chris Mason escribió: > My would be the super block, it is updated more often and so more likely > to get stuck in the array's cache. IIRC, this is exactly the same problem that ZFS users have been hitting. Some users got cheap disks that don't honour barriers correctly, so their uberblock didn't have the correct data. They developed an app that tries to rollback transactions to get the pool into a sane state...I guess that fsck will be able to do that at some point? Stupid question from someone who is not a fs dev...it's not possible to solve this issue by doing some sort of "superblock journaling"? Since there are several superblock copies you could: -Modify a secondary superblock copy to point to the tree root block that still has not been written to disk -Write whatever tree root block has been COW'ed -Modify the primary superblock So in case of these failures, mount code could look in the secondary superblock copy before failing. Since barriers are not being honoured, there's still a possibility that the tree root blocks would be written before the secondary superblock block that was submitted before, but that problem would be much harder to hit I guess. But maybe the fs code can not know where the tree root blocks are going to be written before writting them, and hence it can't generate a valid superblock? Sorry if all this has not sense at all, I'm just wondering if there's a way to solve these drive issues without any kind of recovery tools -- 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: Proper error handling on NULL pointers
On Jueves 22 Octubre 2009 12:15:59 Andi Drebes escribió: > I'd really appreciate to see a TODO section somewhere in the wiki. [..] There's one (needs updating): http://btrfs.wiki.kernel.org/index.php/Development_timeline Also, http://btrfs.wiki.kernel.org/index.php/Project_ideas has some ideas. -- 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: Proper error handling on NULL pointers
On Lunes 19 Octubre 2009 12:36:13 Andi Drebes escribió: > However, is there any interest in patches fixing these problems? If yes: what > would be the best strategy? Should we start fixing this "layer by layer" -- > the low-level functions first and the high-level functions later on? Or > should use come kind of "vertical approach" -- one low-level function and all > of its callers at once? I don't know what is the developer plan to fix that - apparently it's not in the high-priority list (but it must be certainly in the priority list, anyone who gets out of memory using btrfs will have some chances of getting an oops - but notice that most of the important paths are ready to handle errors reliably and there aren't many bug reports due to bad oom handling, so it doesn't seems to be that critical). I realized that it isn't really helpful to add BUG_ONs to failed allocation paths, the code will oops itself as soon as it tries to use the NULL pointer, so adding BUG_ONs is redundant. Passing the error to the callers and handling all that properly is the real fix, but since it requires auditing the whole FS it's probably not an easy task. I tried to do that with a couple of functions, but Kleen's mail made me realize that it isn't that easy. -- 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 and BUG using btrfs-vol -b
By the way, i think it'd be useful if debug-tree would tell which policy
the fs is applying to each chunk. Something like this:
item 4 key (FIRST_CHUNK_TREE CHUNK_ITEM 8379826176) itemoff 3495
itemsize 112
chunk length 319881216 owner 2 type 17 (data on RAID1)
num_stripes 2
stripe 0 devid 2 offset 2265382912
stripe 1 devid 1 offset 989003776
Index: btrfs-progs-unstable/print-tree.c
===
--- btrfs-progs-unstable.orig/print-tree.c 2009-10-07 16:44:53.013210615
+0200
+++ btrfs-progs-unstable/print-tree.c 2009-10-07 21:37:46.162546261 +0200
@@ -79,15 +79,37 @@
return 0;
}
+static void print_chunk_type(u64 chunk_flags)
+{
+ printf(" type %llu (", chunk_flags);
+
+ if (chunk_flags & BTRFS_BLOCK_GROUP_DATA)
+ printf("data");
+ if (chunk_flags & BTRFS_BLOCK_GROUP_METADATA)
+ printf("metadata");
+ if (chunk_flags & BTRFS_BLOCK_GROUP_SYSTEM)
+ printf("system??");
+ if (chunk_flags & BTRFS_BLOCK_GROUP_DUP)
+ printf("dup??");
+ if (chunk_flags & BTRFS_BLOCK_GROUP_RAID0)
+ printf(" on RAID0");
+ if (chunk_flags & BTRFS_BLOCK_GROUP_RAID1)
+ printf(" on RAID1");
+ if (chunk_flags & BTRFS_BLOCK_GROUP_RAID10)
+ printf(" on RAID10");
+ printf(") ");
+}
+
static void print_chunk(struct extent_buffer *eb, struct btrfs_chunk *chunk)
{
int num_stripes = btrfs_chunk_num_stripes(eb, chunk);
int i;
- printf("\t\tchunk length %llu owner %llu type %llu num_stripes %d\n",
+ printf("\t\tchunk length %llu owner %llu",
(unsigned long long)btrfs_chunk_length(eb, chunk),
- (unsigned long long)btrfs_chunk_owner(eb, chunk),
- (unsigned long long)btrfs_chunk_type(eb, chunk),
- num_stripes);
+ (unsigned long long)btrfs_chunk_owner(eb, chunk));
+ print_chunk_type((unsigned long long)btrfs_chunk_type(eb, chunk));
+ printf("num_stripes %d\n", num_stripes);
+
for (i = 0 ; i < num_stripes ; i++) {
printf("\t\t\tstripe %d devid %llu offset %llu\n", i,
(unsigned long long)btrfs_stripe_devid_nr(eb, chunk, i),
--
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 and BUG using btrfs-vol -b
On Wednesday 07 October 2009 21:45:29 Chris Mason escribió: > I'm afraid this is good old enospc. Balancing still needs some work to > be completely safe. I've tried using less data and raid1, but I can't reproduce it. -- 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 and BUG using btrfs-vol -b
On Wednesday 07 October 2009 16:33:09 Chris Mason escribió: > Ok, in this case you ended up with raid0 on the data. If you: > > mkfs.btrfs -d raid1 /dev/loop0 /dev/loop1 you'll get data raid1. I got a BUG...but it may be a different bug. Unlike the last time, I didn't even need to zero one of the "disks", the second I rebalanced it oopsed: [ 705.060358] btrfs: relocating block group 4194304 flags 4 [ 1006.106133] btrfs: relocating block group 570428 flags 18 [ 1006.336521] btrfs: found 1 extents [ 1006.469967] btrfs: relocating block group 5384896512 flags 20 [ 1006.471043] btrfs allocation failed flags 20, wanted 4096 [ 1006.471048] space_info has 317378560 free, is full [ 1006.471052] space_info total=319881216, pinned=16384, delalloc=0, may_use=0, used=2355200, root=2875392, super=131072, reserved=0 [ 1006.471058] block group 5384896512 has 319881216 bytes, 2355200 used 16384 pinned 0 reserved [ 1006.471063] entry offset 5384896512, bytes 483328, bitmap yes [ 1006.471065] block group has cluster?: yes [ 1006.471067] 1 blocks of free space at or bigger than bytes is [ 1006.471092] [ cut here ] [ 1006.471094] kernel BUG at fs/btrfs/transaction.c:1001! [ 1006.471098] invalid opcode: [#1] PREEMPT SMP [ 1006.471103] last sysfs file: /sys/devices/virtual/block/loop0/range [ 1006.471106] CPU 0 [ 1006.471109] Modules linked in: ppp_deflate bsd_comp ppp_async crc_ccitt btrfs zlib_deflate crc32c libcrc32c loop ppp_generic slhc kvm_intel kvm i915 snd_ca0106 snd_rawmidi drm_kms_helper snd_ac97_codec ac97_bus cfbcopyarea snd_pcm_oss video snd_mixer_oss backlight snd_pcm snd_timer cfbimgblt processor wacom intel_agp cfbfillrect button snd soundcore snd_page_alloc usbhid fan fuse ehci_hcd uhci_hcd thermal thermal_sys atl1 mii usbcore [ 1006.471159] Pid: 8207, comm: btrfs-vol Not tainted 2.6.32-rc3 #1 System Product Name [ 1006.471162] RIP: 0010:[] [] btrfs_commit_transaction+0x6c5/0x6f0 [btrfs] [ 1006.471183] RSP: 0018:8800bc285a78 EFLAGS: 00010286 [ 1006.471186] RAX: ffe4 RBX: 8800bdef5800 RCX: 0016 [ 1006.471189] RDX: RSI: 8800bc2859f8 RDI: 8800a86d8060 [ 1006.471192] RBP: 8800bc285b18 R08: R09: [ 1006.471195] R10: R11: R12: 8800a181f5c0 [ 1006.471199] R13: 8800a1eb1ae0 R14: 8800bc285ab8 R15: 8800a1eb1b50 [ 1006.471202] FS: 7f7c5427f730() GS:88000180() knlGS: [ 1006.471206] CS: 0010 DS: ES: CR0: 8005003b [ 1006.471209] CR2: 02812500 CR3: a2f88000 CR4: 26f0 [ 1006.471212] DR0: DR1: DR2: [ 1006.471215] DR3: DR6: 0ff0 DR7: 0400 [ 1006.471219] Process btrfs-vol (pid: 8207, threadinfo 8800bc284000, task 88000b2bae00) [ 1006.471221] Stack: [ 1006.471223] 8800bc285ad8 0206 0001bf15ad00 0110 [ 1006.471229] <0> 8800a181f5c0 0004 8800a1eb1b80 8800a1eb1ae0 [ 1006.471235] <0> 88000b2bae00 8106eb30 8800bc285ad0 [ 1006.471242] Call Trace: [ 1006.471250] [] ? autoremove_wake_function+0x0/0x40 [ 1006.471264] [] ? start_transaction+0x11e/0x170 [btrfs] [ 1006.471285] [] relocate_block_group+0xec/0x4b0 [btrfs] [ 1006.471291] [] ? sub_preempt_count+0x59
Re: Warning and BUG using btrfs-vol -b
On Wednesday 07 October 2009 05:17:54 Chris Mason escribió: > Thanks, I'll try to reproduce. Which raid level did you use for data? > If not raid1, could you try with raid1? ;) I'm not sure, since the utils won't tell. I mkfs'ed and mounted one of the 3.5GB files with no special options, and copied some files on it. I mkfs'ed the second file, put it in a loop device, and added it to the pool with btrfs-vol -a. Then I run btrfs-vol -b and I copied more files and rebalanced several times. Then I zeroed one of the files used as disks, and tried to read the files in the volume (unsucessfully). Then I rebalanced, and I hit the oops. It seems to be very reproducible. -- 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] Fix possible pointer dereference
We should always check btrfs_alloc_path(). Some places BUG(), others return -ENOMEM, btrfs_insert_dir_item() seems like it can return safely. Signed-off-by: Diego Calleja --- linux/fs/btrfs/dir-item.c.BAK 2009-10-06 19:00:48.887361896 +0200 +++ linux/fs/btrfs/dir-item.c 2009-10-06 19:01:00.329132291 +0200 @@ -147,6 +147,9 @@ int btrfs_insert_dir_item(struct btrfs_t key.offset = btrfs_name_hash(name, name_len); path = btrfs_alloc_path(); + if (!path) + return -ENOMEM; + path->leave_spinning = 1; data_size = sizeof(*dir_item) + name_len; -- 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 and BUG using btrfs-vol -b
I was playing with btrfs with 2 files of 3.5 GB (using loop), I completely zeroed one of the files. As expected, I had checksum failures, and I run btrfs-vol -b just to see what happened, and I got this (using -rc3): [25765.340492] btrfs csum failed ino 260 off 122880 csum 2566472073 private 3262812575 [25765.340530] btrfs csum failed ino 260 off 118784 csum 2566472073 private 1515197691 [25765.340560] btrfs csum failed ino 260 off 114688 csum 2566472073 private 1467250717 [25765.340589] btrfs csum failed ino 260 off 110592 csum 2566472073 private 551456760 [25765.340618] btrfs csum failed ino 260 off 106496 csum 2566472073 private 2751401677 [25765.340647] btrfs csum failed ino 260 off 102400 csum 2566472073 private 2648834377 [25765.340675] btrfs csum failed ino 260 off 98304 csum 2566472073 private 467965630 [25765.340703] btrfs csum failed ino 260 off 94208 csum 2566472073 private 3164409631 [25765.340732] btrfs csum failed ino 260 off 90112 csum 2566472073 private 2042500030 [25765.340760] btrfs csum failed ino 260 off 86016 csum 2566472073 private 830495785 [25809.292651] btrfs: relocating block group 3541041152 flags 9 [25809.416493] __ratelimit: 158 callbacks suppressed [25809.416498] btrfs csum failed ino 257 off 61440 csum 2566472073 private 1989812792 [25809.416537] btrfs csum failed ino 257 off 57344 csum 2566472073 private 3105762401 [25809.416603] btrfs csum failed ino 257 off 53248 csum 2566472073 private 2215503813 [25809.416719] btrfs csum failed ino 257 off 323584 csum 2566472073 private 883932373 [25809.416731] btrfs csum failed ino 257 off 49152 csum 2566472073 private 1747807236 [25809.416752] btrfs csum failed ino 257 off 319488 csum 2566472073 private 2519068844 [25809.416774] btrfs csum failed ino 257 off 45056 csum 2566472073 private 3487590687 [25809.416783] btrfs csum failed ino 257 off 315392 csum 2566472073 private 2599709027 [25809.416813] btrfs csum failed ino 257 off 311296 csum 2566472073 private 157132003 [25809.416823] btrfs csum failed ino 257 off 40960 csum 2566472073 private 599615997 [25809.657271] [ cut here ] [25809.657294] WARNING: at fs/btrfs/relocation.c:3588 btrfs_relocate_block_group+0x27f/0x390 [btrfs]() [25809.657298] Hardware name: System Product Name [25809.657300] Modules linked in: btrfs loop crc32c libcrc32c ppp_deflate zlib_deflate bsd_comp ppp_async crc_ccitt ppp_generic slhc kvm_intel kvm i915 snd_ca0106 snd_rawmidi drm_kms_helper cfbcopyarea snd_ac97_codec ac97_bus video snd_pcm_oss snd_mixer_oss snd_pcm backlight snd_timer cfbimgblt snd processor button cfbfillrect intel_agp wacom soundcore snd_page_alloc usbhid fan fuse ehci_hcd uhci_hcd thermal thermal_sys usbcore atl1 mii [last unloaded: btrfs] [25809.657350] Pid: 15354, comm: btrfs-vol Not tainted 2.6.32-rc3 #1 [25809.657353] Call Trace: [25809.657361] [] warn_slowpath_common+0x7b/0xc0 [25809.657366] [] warn_slowpath_null+0x14/0x20 [25809.657377] [] btrfs_relocate_block_group+0x27f/0x390 [btrfs] [25809.657390] [] btrfs_relocate_chunk+0x8b/0x5e0 [btrfs] [25809.657404] [] ? map_extent_buffer+0xdb/0xe0 [btrfs] [25809.657417] [] ? unmap_extent_buffer+0x13/0x40 [btrfs] [25809.657431] [] ? btrfs_item_offset+0xe4/0xf0 [btrfs] [25809.657444] [] btrfs_balance+0x1ef/0x27
Re: kernel BUG at fs/btrfs/disk-io.c:2221!
You probably should have CC'ed the btrfs mailing list (I already did in this mail) On Sábado 01 Agosto 2009 11:50:08 Thomas Meyer escribió: > kernel BUG at fs/btrfs/disk-io.c:2221! > invalid opcode: [#1] PREEMPT SMP > last sysfs file: /sys/block/sdc/sdc1/start > CPU 1 > Modules linked in: btrfs olympic forcedeth rndis_wlan floppy [last unloaded: > scsi_wait_scan] > Pid: 23806, comm: umount Tainted: GW 2.6.31-rc4-rt1 #3 MS-7250 > RIP: 0010:[] [] > write_all_supers+0x22f/0x259 [btrfs] > RSP: 0018:88009e575ce8 EFLAGS: 00010292 > RAX: 003a RBX: 8801980889f8 RCX: 88009e575ba8 > RDX: RSI: 0202 RDI: 5661d985 > RBP: 0001 R08: 0002 R09: > R10: R11: 88009e575c88 R12: 88011e0b2000 > R13: R14: 880198088980 R15: 88011e094ed6 > FS: 7fa0ba6ef740() GS:8800280ac000() knlGS:f49ffb70 > CS: 0010 DS: ES: CR0: 8005003b > CR2: 00be1858 CR3: 9204a000 CR4: 06e0 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0400 > Process umount (pid: 23806, threadinfo 88009e574000, task > 8801bbd3a760) > Stack: > 88009e575d10 88011e094ee6 0001 88011e094dcb > <0> 8801980889f8 8439bfff 8439c000 5661d985 > <0> 852b4000 88011e0b2000 88018024f8a0 880091c92d70 > Call Trace: > [] ? btrfs_commit_transaction+0x5ff/0x6d7 [btrfs] > [] ? autoremove_wake_function+0x0/0x55 > [] ? sync_quota_sb+0x58/0x133 > [] ? __sync_filesystem+0x3b/0x82 > [] ? generic_shutdown_super+0x31/0x10c > [] ? kill_anon_super+0x1d/0x71 > [] ? deactivate_super+0x63/0xa6 > [] ? sys_umount+0x2e4/0x32a > [] ? system_call_fastpath+0x16/0x1b > Code: 24 90 01 00 00 48 8b b8 b0 21 00 00 48 83 c7 48 e8 dd 30 7b e1 3b 6c 24 > 10 7e 14 89 ee 48 c7 c7 1a 39 09 a0 31 c0 e8 eb 09 7b e1 <0f> 0b eb fe 31 c0 > 48 8b 54 24 38 65 48 33 14 25 28 00 00 00 74 > RIP [] write_all_supers+0x22f/0x259 [btrfs] > RSP > ---[ end trace 1e2f23bdcf389667 ]--- > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- 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] Remove useless check in find_delalloc_range
'found' is always 0 at that point, so the test is redundant.
Signed-off-by: Diego Calleja
---
fs/btrfs/extent_io.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux/fs/btrfs/extent_io.c
===
--- linux.orig/fs/btrfs/extent_io.c 2009-07-29 01:16:22.010765781 +0200
+++ linux/fs/btrfs/extent_io.c 2009-07-29 01:17:31.874765725 +0200
@@ -1092,8 +1092,7 @@ static noinline u64 find_delalloc_range(
*/
node = tree_search(tree, cur_start);
if (!node) {
- if (!found)
- *end = (u64)-1;
+ *end = (u64)-1;
goto out;
}
--
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] Remove code duplication in comp_keys
comp_keys is duplicating what is done in btrfs_comp_cpu_keys, so just call it. Signed-off-by: Diego Calleja --- fs/btrfs/ctree.c | 14 +- 1 file changed, 1 insertion(+), 13 deletions(-) Index: linux/fs/btrfs/ctree.c === --- linux.orig/fs/btrfs/ctree.c 2009-07-24 00:47:20.936410297 +0200 +++ linux/fs/btrfs/ctree.c 2009-07-24 00:48:02.368160146 +0200 @@ -557,19 +557,7 @@ static int comp_keys(struct btrfs_disk_k btrfs_disk_key_to_cpu(&k1, disk); - if (k1.objectid > k2->objectid) - return 1; - if (k1.objectid < k2->objectid) - return -1; - if (k1.type > k2->type) - return 1; - if (k1.type < k2->type) - return -1; - if (k1.offset > k2->offset) - return 1; - if (k1.offset < k2->offset) - return -1; - return 0; + return btrfs_comp_cpu_keys(&k1, k2); } /* -- 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: Performance results on Experimental branch
On Miércoles 25 Febrero 2009 23:55:08 Steven Pratt escribió: > Unless I am missing something, what you are referring to is a simple > wraping/alignment issue in the key on the long name on the experimental > btrfs. It is the Brown bar. Let me know if this is not the issue. doh, you're right. Sorry, it's time to sleep here ;( -- 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: Performance results on Experimental branch
On Miércoles 25 Febrero 2009 22:07:33 Steven Pratt escribió: > All in all good progress. Results and graphs can be found here: > > http://btrfs.boxacle.net/repository/raid/history/History.html Some graphs seem to be broken...btrfs gets a "transparent" color. For example here: http://btrfs.boxacle.net/repository/raid/history/History_Mail_server_simulation._num_threads=16.FFSB_Ops_per_Sec.png -- 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: btrfs-unstable tree updated to 2.6.29-rc3
El Thu, 29 Jan 2009 11:54:20 -0500, Chris Mason escribió: > The unstable tree hasn't been updated yet, I want to keep it compiling You forgot to update the unstable-standalone tree (or its going to be discontinued?) -- 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] __must_check btrfs_alloc_path()
IMHO it's a good thing to add __must_check in new code where it has sense.
Index: btrfs-unstable-standalone/ctree.c
===
--- btrfs-unstable-standalone.orig/ctree.c 2008-12-29 21:57:15.366588465
+0100
+++ btrfs-unstable-standalone/ctree.c 2008-12-29 21:58:06.878588402 +0100
@@ -43,7 +43,7 @@
memset(p, 0, sizeof(*p));
}
-struct btrfs_path *btrfs_alloc_path(void)
+struct btrfs_path __must_check *btrfs_alloc_path(void)
{
struct btrfs_path *path;
path = kmem_cache_alloc(btrfs_path_cachep, GFP_NOFS);
--
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] always check btrfs_alloc_path() failure
There are some places that don't check at all btrfs_alloc_path() failures,
I added BUG_ON's for all of them, as many other codepaths that don't know
how to handle the failures seem to do.
In case of not applying this patch, I must notice that there's one real
bugfix that should be applied, it's a null pointer dereference on inode.c:
2506: path = btrfs_alloc_path();
2507: path->reada = -1;
2508: BUG_ON(!path);
Index: btrfs-unstable-standalone/dir-item.c
===
--- btrfs-unstable-standalone.orig/dir-item.c 2008-12-29 21:23:16.940588725
+0100
+++ btrfs-unstable-standalone/dir-item.c2008-12-29 21:30:13.654588510
+0100
@@ -146,6 +146,7 @@
btrfs_set_key_type(&key, BTRFS_DIR_ITEM_KEY);
key.offset = btrfs_name_hash(name, name_len);
path = btrfs_alloc_path();
+ BUG_ON(!path);
data_size = sizeof(*dir_item) + name_len;
dir_item = insert_with_overflow(trans, root, path, &key, data_size,
name, name_len);
Index: btrfs-unstable-standalone/export.c
===
--- btrfs-unstable-standalone.orig/export.c 2008-12-29 21:25:33.317589186
+0100
+++ btrfs-unstable-standalone/export.c 2008-12-29 21:26:46.658692859 +0100
@@ -146,6 +146,7 @@
int ret;
path = btrfs_alloc_path();
+ BUG_ON(!path);
key.objectid = dir->i_ino;
btrfs_set_key_type(&key, BTRFS_INODE_REF_KEY);
Index: btrfs-unstable-standalone/extent-tree.c
===
--- btrfs-unstable-standalone.orig/extent-tree.c2008-12-29
21:26:52.133589589 +0100
+++ btrfs-unstable-standalone/extent-tree.c 2008-12-29 21:29:33.000589414
+0100
@@ -1337,6 +1337,7 @@
WARN_ON(num_bytes < root->sectorsize);
path = btrfs_alloc_path();
+ BUG_ON(!path);
path->reada = 1;
key.objectid = bytenr;
key.offset = num_bytes;
@@ -1377,6 +1378,7 @@
key.type = BTRFS_EXTENT_ITEM_KEY;
path = btrfs_alloc_path();
+ BUG_ON(!path);
ret = btrfs_search_slot(NULL, extent_root, &key, path, 0, 0);
if (ret < 0)
goto out;
@@ -2132,6 +2134,7 @@
int num_inserts = 0, max_inserts;
path = btrfs_alloc_path();
+ BUG_ON(!path);
INIT_LIST_HEAD(&insert_list);
INIT_LIST_HEAD(&update_list);
Index: btrfs-unstable-standalone/file-item.c
===
--- btrfs-unstable-standalone.orig/file-item.c 2008-12-29 21:30:59.441588913
+0100
+++ btrfs-unstable-standalone/file-item.c 2008-12-29 21:31:58.836588923
+0100
@@ -160,6 +160,7 @@
struct extent_io_tree *io_tree = &BTRFS_I(inode)->io_tree;
path = btrfs_alloc_path();
+ BUG_ON(!path);
if (bio->bi_size > PAGE_CACHE_SIZE * 8)
path->reada = 2;
@@ -506,6 +507,7 @@
root = root->fs_info->csum_root;
path = btrfs_alloc_path();
+ BUG_ON(!path);
while(1) {
key.objectid = BTRFS_EXTENT_CSUM_OBJECTID;
Index: btrfs-unstable-standalone/file.c
===
--- btrfs-unstable-standalone.orig/file.c 2008-12-29 21:30:18.940839123
+0100
+++ btrfs-unstable-standalone/file.c2008-12-29 21:30:38.941774195 +0100
@@ -293,6 +293,7 @@
u64 extent_end = 0;
path = btrfs_alloc_path();
+ BUG_ON(!path);
ret = btrfs_lookup_file_extent(NULL, root, path, inode->i_ino,
last_offset, 0);
while(1) {
Index: btrfs-unstable-standalone/inode.c
===
--- btrfs-unstable-standalone.orig/inode.c 2008-12-29 21:32:03.109588918
+0100
+++ btrfs-unstable-standalone/inode.c 2008-12-29 21:35:12.321588484 +0100
@@ -2504,8 +2504,8 @@
if (root->ref_cows)
btrfs_drop_extent_cache(inode, new_size & (~mask), (u64)-1, 0);
path = btrfs_alloc_path();
- path->reada = -1;
BUG_ON(!path);
+ path->reada = -1;
/* FIXME, add redo link to tree so we don't leak on crash */
key.objectid = inode->i_ino;
@@ -3182,6 +3182,7 @@
filp->f_pos = 2;
}
path = btrfs_alloc_path();
+ BUG_ON(!path);
path->reada = 2;
btrfs_set_key_type(&key, key_type);
Index: btrfs-unstable-standalone/ioctl.c
===
--- btrfs-unstable-standalone.orig/ioctl.c 2008-12-29 21:35:26.854838809
+0100
+++ btrfs-unstable-standalone/ioctl.c 2008-12-29 21:36:27.742591734 +0100
@@ -292,6 +292,7 @@
u64 test_oid;
u64 parent_oid = BTRFS_I(dir->d_inode)->root->root_key.objectid;
+ BUG_ON(!path);
test_oid = s
Re: Selective Compression/Encryption
El Tue, 9 Dec 2008 13:09:51 -0500, "Lee Trager" <[EMAIL PROTECTED]> escribió: > It does seem that doing it with volumes would limit user control and add > lots of complexity to such a simple task. IMHO, WRT compression it's the contrary. Compression on a per-file basis has never been very succesful (just look at how many windows users use it) because it implies taking a decision for every file on the system. OTOH, volume-level is just a single option to be enabled. I'm of course not arguing that file-level compression shouldn't be possible, im just saying that is way more difficult to administer and that most people (including sysadmins) is most likely to use compression in a per-volume basis. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
"possible circular locking dependency detected"
I got this lockdep warning while running tiobench on a clean btrfs filesystem
with the latest code available (commit 2c41b36dd2f9fb5dee150f20c84895496e0642f2)
But it was a purely read-only workload: only root could write to the
filesystem and I was running tiobench as an user, which was spitting
"denied permission" errors.
[ 5177.201587] ===
[ 5177.201594] [ INFO: possible circular locking dependency detected ]
[ 5177.201601] 2.6.28-rc5-dirty #7
[ 5177.201604] ---
[ 5177.201610] btrfs-transacti/9012 is trying to acquire lock:
[ 5177.201615] (&cache->alloc_mutex){--..}, at: []
btrfs_add_free_space+0x27/0x70 [btrfs]
[ 5177.201648]
[ 5177.201650] but task is already holding lock:
[ 5177.201654] (&fs_info->pinned_mutex){--..}, at: []
btrfs_finish_extent_commit+0x33/0x100 [btrfs]
[ 5177.201692]
[ 5177.201693] which lock already depends on the new lock.
[ 5177.201695]
[ 5177.201698]
[ 5177.201699] the existing dependency chain (in reverse order) is:
[ 5177.201704]
[ 5177.201705] -> #1 (&fs_info->pinned_mutex){--..}:
[ 5177.201712][] __lock_acquire+0x13c9/0x1970
[ 5177.201722][] lock_acquire+0x56/0x80
[ 5177.201728][] mutex_lock_nested+0xb6/0x320
[ 5177.201736][] add_new_free_space+0x37/0xe0 [btrfs]
[ 5177.201755][] cache_block_group+0x2b2/0x320 [btrfs]
[ 5177.201774][] find_free_extent+0x2c4/0x640 [btrfs]
[ 5177.201792][] __btrfs_reserve_extent+0xf4/0x310
[btrfs]
[ 5177.201811][] btrfs_alloc_extent+0x4c/0xc0 [btrfs]
[ 5177.201829][] btrfs_alloc_free_block+0x61/0xa0
[btrfs]
[ 5177.201848][] __btrfs_cow_block+0x966/0xe00 [btrfs]
[ 5177.201865][] btrfs_cow_block+0x136/0x330 [btrfs]
[ 5177.201883][] btrfs_search_slot+0x294/0xb70 [btrfs]
[ 5177.201901][] btrfs_lookup_inode+0x38/0xb0 [btrfs]
[ 5177.201920][] btrfs_update_inode+0x4b/0xd0 [btrfs]
[ 5177.201940][] btrfs_dirty_inode+0x4d/0x70 [btrfs]
[ 5177.201961][] __mark_inode_dirty+0x3a/0x1d0
[ 5177.201968][] touch_atime+0xd8/0x140
[ 5177.201975][] vfs_readdir+0xc6/0xd0
[ 5177.201983][] sys_getdents+0x88/0xe0
[ 5177.201989][] system_call_fastpath+0x16/0x1b
[ 5177.201997][] 0x
[ 5177.202024]
[ 5177.202025] -> #0 (&cache->alloc_mutex){--..}:
[ 5177.202033][] __lock_acquire+0x1512/0x1970
[ 5177.202039][] lock_acquire+0x56/0x80
[ 5177.202046][] mutex_lock_nested+0xb6/0x320
[ 5177.202053][] btrfs_add_free_space+0x27/0x70
[btrfs]
[ 5177.202072][]
btrfs_update_pinned_extents+0x172/0x1d0 [btrfs]
[ 5177.202091][]
btrfs_finish_extent_commit+0x72/0x100 [btrfs]
[ 5177.202110][] btrfs_commit_transaction+0x6f5/0x8b0
[btrfs]
[ 5177.202130][] transaction_kthread+0x231/0x270
[btrfs]
[ 5177.202149][] kthread+0x4e/0x90
[ 5177.202157][] child_rip+0xa/0x11
[ 5177.202163][] 0x
[ 5177.202170]
[ 5177.202171] other info that might help us debug this:
[ 5177.202173]
[ 5177.202177] 3 locks held by btrfs-transacti/9012:
[ 5177.202181] #0: (&fs_info->transaction_kthread_mutex){--..}, at:
[] transaction_kthread+0xf3/0x270 [btrfs]
[ 5177.202206] #1: (&fs_info->tree_reloc_mutex){--..}, at:
[] btrfs_commit_transaction+0x346/0x8b0 [btrfs]
[ 5177.202231] #2: (&fs_info->pinned_mutex){--..}, at: []
btrfs_finish_extent_commit+0x33/0x100 [btrfs]
[ 5177.202254]
[ 5177.202255] stack backtrace:
[ 5177.202260] Pid: 9012, comm: btrfs-transacti Not tainted 2.6.28-rc5-dirty #7
[ 5177.202265] Call Trace:
[ 5177.202271] [] print_circular_bug_tail+0xd8/0xe0
[ 5177.202278] [] __lock_acquire+0x1512/0x1970
[ 5177.202285] [] ? find_usage_backwards+0xdc/0x120
[ 5177.202306] [] ? btrfs_add_free_space+0x27/0x70 [btrfs]
[ 5177.202312] [] lock_acquire+0x56/0x80
[ 5177.202329] [] ? btrfs_add_free_space+0x27/0x70 [btrfs]
[ 5177.202337] [] mutex_lock_nested+0xb6/0x320
[ 5177.202354] [] ? btrfs_add_free_space+0x27/0x70 [btrfs]
[ 5177.202372] [] btrfs_add_free_space+0x27/0x70 [btrfs]
[ 5177.202391] [] btrfs_update_pinned_extents+0x172/0x1d0
[btrfs]
[ 5177.202410] [] btrfs_finish_extent_commit+0x72/0x100
[btrfs]
[ 5177.202429] [] btrfs_commit_transaction+0x6f5/0x8b0
[btrfs]
[ 5177.202437] [] ? autoremove_wake_function+0x0/0x40
[ 5177.202438] [] ? mutex_unlock+0xe/0x10
[ 5177.202438] [] transaction_kthread+0x231/0x270 [btrfs]
[ 5177.202438] [] ? trace_hardirqs_on+0xd/0x10
[ 5177.202438] [] ? _spin_unlock_irqrestore+0x47/0x80
[ 5177.202438] [] ? transaction_kthread+0x0/0x270 [btrfs]
[ 5177.202438] [] kthread+0x4e/0x90
[ 5177.202438] [] child_rip+0xa/0x11
[ 5177.202438] [] ? restore_args+0x0/0x30
[ 5177.202438] [] ? kthread+0x0/0x90
[ 5177.202438] [] ? child_rip+0x0/0x11
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [EMAIL PROTECTED]
More majordo
[PATCH] Fix call to blkdev_issue_discard
Commit 3e6053d76dcbd92b2f9f4ad5ece9bce83149523e adds a gfp_mask parameter
to blkdev_issue_discard, which breaks compilation in btrfs if BIO_RW_DISCARD
is config'ed in:
/home/diego/kernel/btrfs-unstable-standalone/extent-tree.c:1896: error:
too few arguments to function 'blkdev_issue_discard'
I added the parameter - GFP_KERNEL, which is what was the gfp_mask used
before this change.
Signed-off-by: Diego Calleja <[EMAIL PROTECTED]>
Index: btrfs-unstable-standalone/extent-tree.c
===
--- btrfs-unstable-standalone.orig/extent-tree.c2008-11-03
16:13:29.0 +0100
+++ btrfs-unstable-standalone/extent-tree.c 2008-11-03 16:18:23.0
+0100
@@ -1891,9 +1891,16 @@
map_length = num_bytes;
for (i = 0; i < multi->num_stripes; i++, stripe++) {
+ #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28)
+ blkdev_issue_discard(stripe->dev->bdev,
+stripe->physical >> 9,
+map_length >> 9,
+GFP_KERNEL);
+ #else
blkdev_issue_discard(stripe->dev->bdev,
stripe->physical >> 9,
map_length >> 9);
+ #endif
}
kfree(multi);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
