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(>sample[i], , 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] Btrfs progs: quota groups support
On Viernes, 10 de agosto de 2012 15:51:07 Jan Schmidt escribió: From: Arne Jansen sensi...@gmx.net Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net Signed-off-by: Arne Jansen sensi...@gmx.net --- 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:
[816875cc] kmemleak_alloc+0x5c/0xc0
[8114aec3] kmem_cache_alloc_trace+0x163/0x240
[8127a290] btrfs_defrag_file+0xf0/0xb20
[8125d9a5] btrfs_run_defrag_inodes+0x165/0x210
[812479d7] cleaner_kthread+0x177/0x190
[81075c7d] kthread+0x8d/0xa0
[816af5f4] kernel_thread_helper+0x4/0x10
[] 0x
pages is not always freed. Fix it removing the unnecesary additional return.
Signed-off-by: Diego Calleja dieg...@gmail.com
---
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] [8104bbcf] warn_slowpath_common+0x7f/0xc0 [ 235.705796] [8104bc2a] warn_slowpath_null+0x1a/0x20 [ 235.705797] [8116922d] iput+0x1ed/0x210 [ 235.705800] [8123b3ac] btrfs_iget+0x1cc/0x460 [ 235.705804] [815dbc56] ? _raw_spin_unlock+0x16/0x40 [ 235.705807] [8123f8ce] btrfs_run_defrag_inodes+0x12e/0x210 [ 235.705809] [8122a09b] cleaner_kthread+0x18b/0x1a0 [ 235.705811] [815dbe0a] ? _raw_spin_unlock_irqrestore+0x2a/0x60 [ 235.705813] [81229f10] ? transaction_kthread+0x290/0x290 [ 235.705815] [8106e42c] kthread+0x8c/0xa0 [ 235.705818] [815e51f4] kernel_thread_helper+0x4/0x10 [ 235.705820] [81037cde] ? finish_task_switch+0x4e/0xe0 [ 235.705822] [815dbc9c] ? _raw_spin_unlock_irq+0x1c/0x40 [ 235.705824] [815dc64e] ? retint_restore_args+0xe/0xe [ 235.705826] [8106e3a0] ? kthread_worker_fn+0x190/0x190 [ 235.705828] [815e51f0] ? 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: 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: 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
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: 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
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
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
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] [8104f9bb] warn_slowpath_common+0x7b/0xc0 [25809.657366] [8104fa14] warn_slowpath_null+0x14/0x20 [25809.657377] [a0396b7f] btrfs_relocate_block_group+0x27f/0x390 [btrfs] [25809.657390] [a037cfab] btrfs_relocate_chunk+0x8b/0x5e0 [btrfs] [25809.657404] [a0372a0b] ? map_extent_buffer+0xdb/0xe0 [btrfs] [25809.657417] [a0371b13] ? unmap_extent_buffer+0x13/0x40 [btrfs] [25809.657431] [a0366c54] ?
[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 dieg...@gmail.com --- 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
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:[a00589ad] [a00589ad] 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: [a005c510] ? btrfs_commit_transaction+0x5ff/0x6d7 [btrfs] [810884bd] ? autoremove_wake_function+0x0/0x55 [81166dfc] ? sync_quota_sb+0x58/0x133 [8113a1a4] ? __sync_filesystem+0x3b/0x82 [81118cd3] ? generic_shutdown_super+0x31/0x10c [81118e28] ? kill_anon_super+0x1d/0x71 [81119691] ? deactivate_super+0x63/0xa6 [81130949] ? sys_umount+0x2e4/0x32a [8102bf2b] ? 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 [a00589ad] write_all_supers+0x22f/0x259 [btrfs] RSP 88009e575ce8 ---[ 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
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: 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
[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 = snap_src-root_key.objectid;
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: [a03d9e57]
btrfs_add_free_space+0x27/0x70 [btrfs]
[ 5177.201648]
[ 5177.201650] but task is already holding lock:
[ 5177.201654] (fs_info-pinned_mutex){--..}, at: [a039eb53]
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][8026cb99] __lock_acquire+0x13c9/0x1970
[ 5177.201722][8026d196] lock_acquire+0x56/0x80
[ 5177.201728][804f7fe6] mutex_lock_nested+0xb6/0x320
[ 5177.201736][a0396c07] add_new_free_space+0x37/0xe0 [btrfs]
[ 5177.201755][a0396f62] cache_block_group+0x2b2/0x320 [btrfs]
[ 5177.201774][a0397294] find_free_extent+0x2c4/0x640 [btrfs]
[ 5177.201792][a0397704] __btrfs_reserve_extent+0xf4/0x310
[btrfs]
[ 5177.201811][a03995bc] btrfs_alloc_extent+0x4c/0xc0 [btrfs]
[ 5177.201829][a0399691] btrfs_alloc_free_block+0x61/0xa0
[btrfs]
[ 5177.201848][a0388fd6] __btrfs_cow_block+0x966/0xe00 [btrfs]
[ 5177.201865][a0389ca6] btrfs_cow_block+0x136/0x330 [btrfs]
[ 5177.201883][a038fdc4] btrfs_search_slot+0x294/0xb70 [btrfs]
[ 5177.201901][a03a2838] btrfs_lookup_inode+0x38/0xb0 [btrfs]
[ 5177.201920][a03ad86b] btrfs_update_inode+0x4b/0xd0 [btrfs]
[ 5177.201940][a03b07cd] btrfs_dirty_inode+0x4d/0x70 [btrfs]
[ 5177.201961][802edc1a] __mark_inode_dirty+0x3a/0x1d0
[ 5177.201968][802e2438] touch_atime+0xd8/0x140
[ 5177.201975][802dccc6] vfs_readdir+0xc6/0xd0
[ 5177.201983][802dce38] sys_getdents+0x88/0xe0
[ 5177.201989][8020bb7b] system_call_fastpath+0x16/0x1b
[ 5177.201997][] 0x
[ 5177.202024]
[ 5177.202025] - #0 (cache-alloc_mutex){--..}:
[ 5177.202033][8026cce2] __lock_acquire+0x1512/0x1970
[ 5177.202039][8026d196] lock_acquire+0x56/0x80
[ 5177.202046][804f7fe6] mutex_lock_nested+0xb6/0x320
[ 5177.202053][a03d9e57] btrfs_add_free_space+0x27/0x70
[btrfs]
[ 5177.202072][a0397cd2]
btrfs_update_pinned_extents+0x172/0x1d0 [btrfs]
[ 5177.202091][a039eb92]
btrfs_finish_extent_commit+0x72/0x100 [btrfs]
[ 5177.202110][a03a9fc5] btrfs_commit_transaction+0x6f5/0x8b0
[btrfs]
[ 5177.202130][a03a44c1] transaction_kthread+0x231/0x270
[btrfs]
[ 5177.202149][80259cde] kthread+0x4e/0x90
[ 5177.202157][8020ccc9] 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:
[a03a4383] transaction_kthread+0xf3/0x270 [btrfs]
[ 5177.202206] #1: (fs_info-tree_reloc_mutex){--..}, at:
[a03a9c16] btrfs_commit_transaction+0x346/0x8b0 [btrfs]
[ 5177.202231] #2: (fs_info-pinned_mutex){--..}, at: [a039eb53]
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] [8026b3a8] print_circular_bug_tail+0xd8/0xe0
[ 5177.202278] [8026cce2] __lock_acquire+0x1512/0x1970
[ 5177.202285] [8026899c] ? find_usage_backwards+0xdc/0x120
[ 5177.202306] [a03d9e57] ? btrfs_add_free_space+0x27/0x70 [btrfs]
[ 5177.202312] [8026d196] lock_acquire+0x56/0x80
[ 5177.202329] [a03d9e57] ? btrfs_add_free_space+0x27/0x70 [btrfs]
[ 5177.202337] [804f7fe6] mutex_lock_nested+0xb6/0x320
[ 5177.202354] [a03d9e57] ? btrfs_add_free_space+0x27/0x70 [btrfs]
[ 5177.202372] [a03d9e57] btrfs_add_free_space+0x27/0x70 [btrfs]
[ 5177.202391] [a0397cd2] btrfs_update_pinned_extents+0x172/0x1d0
[btrfs]
[ 5177.202410] [a039eb92]
