[PATCH] btrfs read error corrected message floods the console during recovery
From: Anand Jain Changing printk_in_rcu to printk_ratelimited_in_rcu will suffice --- fs/btrfs/extent_io.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index aaa12c1..5ad8743 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -1918,7 +1918,7 @@ int repair_io_failure(struct btrfs_mapping_tree *map_tree, u64 start, return -EIO; } - printk_in_rcu(KERN_INFO "btrfs read error corrected: ino %lu off %llu " + printk_ratelimited_in_rcu(KERN_INFO "btrfs read error corrected: ino %lu off %llu " "(dev %s sector %llu)\n", page->mapping->host->i_ino, start, rcu_str_deref(dev->name), sector); -- 1.7.1 -- 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] Seg fault when csum-tree root is corrupted.
From: Anand Jain
Segmentation fault with the following trace when csum-tree is
deliberately corrupted using btrfs-corrupt-block
read block failed check_tree_block
Couldn't setup csum tree
checking extents
Check tree block failed, want=29376512, have=0
::
read block failed check_tree_block < !!
Segmentation fault (core dumped) <--- !!
The below fix will redirect btrfsck user to use --init-csum-tree
when csum root is corrupted
---
btrfsck.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/btrfsck.c b/btrfsck.c
index 7aac736..6ced7b5 100644
--- a/btrfsck.c
+++ b/btrfsck.c
@@ -3483,6 +3483,10 @@ int main(int ac, char **av)
fprintf(stderr, "Critical roots corrupted, unable to fsck the
FS\n");
return -EIO;
}
+ if (!extent_buffer_uptodate(info->csum_root->node) && !init_csum_tree) {
+ fprintf(stderr, "Checksum root corrupted, run 'btrfsck
--init-csum-tree'\n");
+ return -EIO;
+ }
root = info->fs_root;
--
1.7.1
--
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: Please hammer my for-linus branch
On 2 July 2012 21:34, Josef Bacik wrote:
> On Sun, Jul 01, 2012 at 09:35:01PM -0600, Daniel J Blueman wrote:
>> > Hi everyone,
>> >
>> > I've got a nice set of fixes from Josef, Jan, Ilya and others in my
>> > for-linus branch:
>> >
>> > git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
>> > for-linus
>> >
>> > Some of the changes are fixes for the tree logging code, so I ran some
>> > extra crash runs against them Friday night.
>> >
>> > I ended up with a new crash in the tree log directory deletion replay
>> > code, so I didn't send out the pull request to Linus.
>> >
>> > It isn't clear yet if the new crash is because I was testing differently
>> > or if it is a regression. I'm nailing it down this weekend, but please
>> > give my for-linus a shot.
>>
>> With this branch (3.4.0), my test has consistently been hitting the
>> BUG_ON(owner < BTRFS_FIRST_FREE_OBJECTID) in
>> insert_inline_extent_backref [1]. This is followed by a string of
>> other issues [2] and a hard lockup, so I used netconsole to collect
>> this.
>>
>> I'm preparing my btrfs test for xfstests integration, but can slip you
>> it if interested. It hits this case in ~30s.
>>
>
> Can you apply this and capture the output, I have a feeling I know what this
> is.
> Thanks,
>
> Josef
>
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index 5775dc4..917ea70 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -1766,7 +1766,13 @@ int insert_inline_extent_backref(struct
> btrfs_trans_handle *trans,
>bytenr, num_bytes, parent,
>root_objectid, owner, offset, 1);
> if (ret == 0) {
> - BUG_ON(owner < BTRFS_FIRST_FREE_OBJECTID);
> + if (owner < BTRFS_FIRST_FREE_OBJECTID) {
> + printk(KERN_ERR "bad inline extent, bytenr=%Lu, "
> + "num_bytes=%Lu, parent=%Lu, root=%Lu,
> owner=%Lu"
> + ", offset=%Lu\n", bytenr, num_bytes, parent,
> + root_objectid, owner, offset);
> + BUG_ON(owner < BTRFS_FIRST_FREE_OBJECTID);
> + }
> update_inline_extent_backref(trans, root, path, iref,
> refs_to_add, extent_op);
> } else if (ret == -ENOENT) {
Bo's additional condition 'root_objectid == BTRFS_TREE_LOG_OBJECTID'
seemed to hold it off.
Here is the debug you asked for [1]. After we've determined the right
fix for this issue, I'll post the other issues I was seeing.
Thanks!
Daniel
--- [1]
device fsid c5cf90d4-0301-4877-8f34-e8e82fe6ab0a devid 1 transid 3 /dev/ram3
device fsid c5cf90d4-0301-4877-8f34-e8e82fe6ab0a devid 2 transid 3 /dev/ram0
device fsid c5cf90d4-0301-4877-8f34-e8e82fe6ab0a devid 1 transid 4 /dev/ram3
btrfs: allowing degraded mounts
btrfs: force zlib compression
btrfs: disabling disk space caching
btrfs: enabling auto defrag
btrfs: enabling auto recovery
btrfs: no dev_stats entry found for device /dev/ram0 (devid 2) (OK on
first mount after mkfs)
btrfs: no dev_stats entry found for device /dev/ram3 (devid 1) (OK on
first mount after mkfs)
btrfs: relocating block group 512425984 flags 20
btrfs: found 2 extents
btrfs: relocating block group 190382080 flags 9
btrfs: found 4756 extents
btrfs: found 4756 extents
bad inline extent, bytenr=36909056, num_bytes=4096, parent=0, root=5,
owner=0, offset=0
[ cut here ]
kernel BUG at fs/btrfs/extent-tree.c:1774!
invalid opcode: [#1] SMP DEBUG_PAGEALLOC CPU 0
Modules linked in:
brd dm_crypt dm_mod kvm_intel kvm uvcvideo videobuf2_core videodev
videobuf2_vmalloc videobuf2_memops coretemp microcode iwlwifi
netconsole btrfs i915 cfbcopyarea cfbimgblt cfbfillrect video
Pid: 8055, comm: btrfs-endio-wri Not tainted 3.4.0-debug+ #5 Dell Inc.
Latitude E5420/0H5TG2
RIP: 0010:[] []
insert_inline_extent_backref+0x11b/0x120 [btrfs]
RSP: 0018:880200415a40 EFLAGS: 00010282
RAX: 006d RBX: 88020e99c1b0 RCX:
RDX: 8103cde5 RSI: 0001 RDI: 8103d170
RBP: 880200415ac0 R08: 0002 R09:
R10: R11: R12: 88020e7f7000
R13: 88020ef80e60 R14: R15: 1000
FS: () GS:88022ec0() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 7f6916262000 CR3: 000221e24000 CR4: 000407f0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process btrfs-endio-wri (pid: 8055, threadinfo 880200414000, task
880222029ee0)
Stack:
0005
88020001 a0089be5 880200415aa0 02333000
8801f6f15000 0ea1 8801f6f15000 88
Re: raid10 make_request failure during iozone benchmark upon btrfs
On Tue, 03 Jul 2012 03:13:33 +0100 Kerin Millar wrote: > Hi, > > On 03/07/2012 02:39, NeilBrown wrote: > > [snip] > > >>> Could you please double check that you are running a kernel with > >>> > >>> commit aba336bd1d46d6b0404b06f6915ed76150739057 > >>> Author: NeilBrown > >>> Date: Thu May 31 15:39:11 2012 +1000 > >>> > >>> md: raid1/raid10: fix problem with merge_bvec_fn > >>> > >>> in it? > >> > >> I am indeed. I searched the list beforehand and noticed the patch in > >> question. Not sure which -rc it landed in but I checked my source tree > >> and it's definitely in there. > >> > >> Cheers, > >> > >> --Kerin > > > > Thanks. > > Looking at it again I see that it is definitely a different bug, that patch > > wouldn't affect it. > > > > But I cannot see what could possibly be causing the problem. > > You have a 256K chunk size, so requests should be limited to 512 sectors > > aligned at a 512-sector boundary. > > However all the requests that a causing errors are 512 sectors long, but > > aligned on a 256-sector boundary (which is not also 512-sector). This is > > wrong. > > I see. > > > > > It could be that btrfs is submitting bad requests, but I think it always > uses > > bio_add_page, and bio_add_page appears to do the right thing. > > It could be that dm-linear is causing problem, but it seems to correctly > after > > the underlying device for alignment, and reports that alignment to > > bio_add_page. > > It could be that md/raid10 is the problem but I cannot find any fault in > > raid10_mergeable_bvec - performs much the same tests that the > > raid01 make_request function does. > > > > So it is a mystery. > > > > Is this failure repeatable? > > Yes, it's reproducible with 100% consistency. Furthermore, I tried to > use the btrfs volume as a store for the package manager, so as to try > with a 'realistic' workload. Many of these errors were triggered > immediately upon invoking the package manager. In case it matters, the > package manager is portage (in Gentoo Linux) and the directory structure > entails a shallow directory depth with a large number of distributed > small files. I haven't been able to reproduce with xfs, ext4 or reiserfs. > > > > > If so, could you please insert > > WARN_ON_ONCE(1); > > in drivers/md/raid10.c where it prints out the message: just after the > > "bad_map:" label. > > > > Also, in raid10_mergeable_bvec, insert > > WARN_ON_ONCE(max< 0); > > just before > >if (max< 0) > >/* bio_add cannot handle a negative return */ > >max = 0; > > > > and then see if either of those generate a warning, and post the full stack > > trace if they do. > > OK. I ran iozone again on a fresh filesystem, mounted with the default > options. Here's the trace that appears, just before the first > make_request_bug message: > > WARNING: at drivers/md/raid10.c:1094 make_request+0xda5/0xe20() > Hardware name: ProLiant MicroServer > Modules linked in: btrfs zlib_deflate lzo_compress kvm_amd kvm sp5100_tco > i2c_piix4 > Pid: 1031, comm: btrfs-submit-1 Not tainted 3.5.0-rc5 #3 > Call Trace: > [] ? warn_slowpath_common+0x67/0xa0 > [] ? make_request+0xda5/0xe20 > [] ? __split_and_process_bio+0x2d4/0x600 > [] ? set_next_entity+0x29/0x60 > [] ? pick_next_task_fair+0x63/0x140 > [] ? md_make_request+0xbf/0x1e0 > [] ? generic_make_request+0xaf/0xe0 > [] ? submit_bio+0x63/0xe0 > [] ? try_to_del_timer_sync+0x7d/0x120 > [] ? run_scheduled_bios+0x23a/0x520 [btrfs] > [] ? worker_loop+0x120/0x520 [btrfs] > [] ? btrfs_queue_worker+0x2e0/0x2e0 [btrfs] > [] ? kthread+0x85/0xa0 > [] ? kernel_thread_helper+0x4/0x10 > [] ? kthread_freezable_should_stop+0x60/0x60 > [] ? gs_change+0xb/0xb > > Cheers, > > --Kerin Thanks. Looks like it is a btrfs bug - so a big "hello" to linux-btrfs :-) The symptom is that iozone on btrfs on md/raid10 can result in [ 919.893454] md/raid10:md0: make_request bug: can't convert block across chunks or bigger than 256k 6653500160 256 [ 919.893465] btrfs: bdev /dev/mapper/vg0-test errs: wr 1, rd 0, flush 0, corrupt 0, gen 0 i.e. RAID10 has a 256K chunk size, but is getting 256K requests which overlap two chunks - the last half of one chunk and the first half of the next. That isn't allowed and raid10_mergeable_bvec, called by bio_add_page, should prevent it. However btrfs_map_bio() sets ->bi_sector to a new value without verifying that the resulting bio is still acceptable - which it isn't. The core problem is that you cannot build a bio for one location, then use it freely at another location. md/raid1 handles this by checking each addition to a bio against all the possible location that it might read/write it. Maybe btrfs could do the same. Alternately we could work with Kent Overstreet (of bcache fame) to remove the restriction that the fs must make the bio compatible with the device - instead requiring the device to split bios when needed,
Re: [PATCH 1/3] Btrfs-progs: add support to set subvolume/snapshot readonly
On 07/02/2012 06:00 PM, Ilya Dryomov wrote:
> On Mon, Jul 02, 2012 at 10:07:42AM +0800, Liu Bo wrote:
>> On 06/29/2012 06:21 PM, Ilya Dryomov wrote:
>>
>>> On Fri, Jun 29, 2012 at 06:00:36PM +0800, Liu Bo wrote:
Setting subvolume/snapshot readonly has been missing for a long time.
With this patch, we can set a subvolume/snapshot readonly via:
obtrfs subvolume set-ro
>>> Alexander's 'btrfs property' patches do exactly this, but in a much more
>>> generic and extensible way. 'btrfs property' subgroup provides a
>>> uniform interface for getting and setting properties of filesystem
>>> objects in general, not only those of subvolumes and snapshots. It
>>> provides a much better user interface, and it also allows us to easily
>>> rethink kernel-user interface for generic get/set in future.
>>>
>>
>> Thanks for the explanation!
>>
>> But I prefer keeping the current categories
>> {subvolume,filesystem,device,...}:
>>
>> o Compatibility, we cannot remove the old commands until we make sure that
>> no users will
>> use them.
>
> We are not going to remove old commands any time soon. However, adding
> new ones that clearly fall into get/set category, is not a good idea.
> Especially when there is a generic interface on its way.
>
>> o We've three properties {default, readonly, lable}, is it worthy making
>> another new interface?
>
> It's not just about subvolumes. There will be a lot more properties on
> the table as filesystem matures, for example device speeds, subvolume
> profiles, quotas.
>
>> o Current categories are clear and clean.
>
> Once again, it's not just about subvolumes. Current categories are
> indeed clear, but adding two commands for each non-trivial property that
> comes up in future does not seem practical to me.
>
I see, that's reasonable. :)
Besides set/get-ro and get-default, I also want to have 'btrfs subvolume list'
work as 'ls', that is,
it can list not only all of items, but also a single item.
And I have made a patch for that (it refers to [PATCH 3/3] Btrfs-progs: add 's'
option for 'btrfs subvolume list').
What's your opinion about it?
thanks,
liubo
> Thanks,
>
> Ilya
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] Btrfs-progs: make get default report correctly
On 07/02/2012 05:45 PM, Ilya Dryomov wrote: > On Mon, Jul 02, 2012 at 09:39:45AM +0800, Liu Bo wrote: >> On 06/29/2012 06:36 PM, Ilya Dryomov wrote: >> >>> On Fri, Jun 29, 2012 at 06:00:37PM +0800, Liu Bo wrote: We have both set-default and get-default, but actually our get-default does not show which one is the default one. This patch plus the kernel side patch fix this. >>> Are you referring to the fact that get-default in Chris' btrfs-progs >>> master lists all subvolumes instead of showing the default one? If so, >>> I fixed that problem a while ago, patch is in Hugo's integration branch. >>> >> >> So can you please show me a link about your patch? > > I'm sorry, it turns out Hugo hasn't pushed it yet. Here is a link: > http://thread.gmane.org/gmane.comp.file-systems.btrfs/16187/ > Fairly good patches. thanks, liubo > Thanks, > > Ilya > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Check for failure in open_ctree() call. (LP: #926186)
---
btrfstune.c |4
1 file changed, 4 insertions(+)
diff --git a/btrfstune.c b/btrfstune.c
index 47830c5..f746e14 100644
--- a/btrfstune.c
+++ b/btrfstune.c
@@ -107,6 +107,10 @@ int main(int argc, char *argv[])
}
root = open_ctree(device, 0, 1);
+ if (!root) {
+ fprintf(stderr, "unable to open ctree\n");
+ return 1;
+}
if (seeding_flag) {
ret = update_seeding_flag(root, seeding_value);
--
1.7.9.5
--
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 GPF in read_extent_buffer() while scrubbing with kernel 3.4.2
On Tue, Jul 03, 2012 at 02:01:21AM +0300, Sami Liedes wrote: > The oops is transcribed from photos, so it may contain some errors. I > tried to be careful, and double checked the backtrace. Forgot to menion, the fs is a two-partition filesystem, with both data and metadata mirrored. Label: none uuid: f26f08b1-89e6-4f2d-b7f9-857010dd2517 Total devices 2 FS bytes used 778.31GB devid2 size 1.07TB used 1.05TB path /dev/dm-6 devid1 size 1.07TB used 1.05TB path /dev/dm-5 Sami signature.asc Description: Digital signature
btrfs GPF in read_extent_buffer() while scrubbing with kernel 3.4.2
Hi, I just got this oops on a computer running 3.4.2. A few minutes before I had started "btrfs device scrub /" and had a watcher process running "btrfs scrub status /" every 5 seconds. After a few gigabytes of scrubbing, I got this crash. The oops is transcribed from photos, so it may contain some errors. I tried to be careful, and double checked the backtrace. Sami general protection fault: [#1] SMP CPU 4 Modules linked in: tcp_diag inet_diag nfnetlink_log nfnetlink ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs reiserfs ext3 jbd ext2 ip6_tables ebtable_nat ebtables cn rfcomm bnep parport_pc ppdev lp parport tun cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_conservative binfmt_misc fuse nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc iptable_filter ipt_MASQUERADE ipt_REDIRECT iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ip_tables x_tables xfs ext4 jbd2 mbcache radeon drm_kms_helper ttm drm i2c_algo_bit loop kvm_intel kvm snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_usb_audio snd_usbmidi_lib snd_hwdep snd_pcm_oss snd_mixer_oss joydev snd_pcm acpi_cpufreq snd_page_alloc snd_seq_midi snd_seq_midi_event snd_rawmi di ath3k snd_seq snd_seq_device snd_timer iTCO_wdt bluetooth eeepci_wmi asus_wmi sparse_keymap crc16 rfkill pcspkr psmouse coretemp serio_raw evdev mperf pci_hotplug i2c_i801 i2c_core processor button intel_agp snd mxm_wmi video wmi intel_gtt microcode soundcore sha256_generic dm_crypt dm_mod raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq md_mod nbd btrfs libcrc32c zlib_deflate sd_mod crc_t10dif crc32c_intel ghash_cmulni_intel firewire_ohci r8196 firewire_core ahci aesni_intel libahci mii crc_itu_t aes_x86_64 libata aes_generic cryptd scsi_mod e1000e thermal fa n thermal_sys [last unloaded: scsi_wait_scan] Pid: 30863, comm: btrfs-endio-met Tainted: GW3.4.2 #1 System manufacturer System Product Name/P8P67 EVO RIP: 0010:[] [] memcpy+0xd/0x110 RSP: :88003174dba8 EFLAGS: 00010202 RAX: 88003174dc8f RBX: 0011 RCX: 0002 RDX: 0001 RSI: 00050803 RDI: 88003174dc8f RBP: 88003174dbf0 R08: 000a R09: R10: R11: R12: 88003174dca0 R13: 8800659f42b0 R14: 0048 R15: 0011 FS: () GS:88021ed0() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0973c000 CR3: 000167ef3000 CR4: 000407e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process btrfs-endio-met (pid: 30863, threadinfo 88003174c000, task 88006f818000) Stack: a026bd6b 8801960f5000 8003 1000 88003174dc58 03dd 88000ac13c60 88003174dc58 696f70203a61685f 88003174dc00 a026904d 88003174dcd0 Call Trace: [] ? read_extent_buffer+0xbb/0x110 [btrfs] [] btrfs_node_key+0x1d/0x20 [btrfs] [] __readahead_hook.isra.5+0x3c0/0x420 [btrfs] [] btree_readahead_hook+0x1f/0x40 [btrfs] [] btree_readpage_end_io_hook+0x111/0x260 [btrfs] [] ? find_first_extent_bit_state+0x22/0x80 [btrfs] [] end_bio_extent_readpage+0xcb/0xa30 [btrfs] [] ? end_workqueue_fn+0x31/0x50 [btrfs] [] bio_endio+0x18/0x30 [] end_workqueue_fn+0x3c/0x50 [btrfs] [] worker_loop+0x157/0x560 [btrfs] [] ? btrfs_queue_worker+0x310/0x310 [btrfs] [] kthread+0x8e/0xa0 [] kernel_thread_helper+0x4/0x10 [] ? flush_kthread_worker+0x70/0x70 [] ? gs_change+0x13/0x13 Code: 4e 48 83 c4 08 5b 5d c3 66 0f 1f 44 00 00 e8 eb fb ff ff eb e1 90 90 90 90 90 90 90... 8 4c 8b 56 10 4c RIP [] memcpy+0xd/0x110 RSP signature.asc Description: Digital signature
Re: no dev_stats entry found / OK on first mount after mkfs
On Tue, 3 Jul 2012 at 01:41, Ilya Dryomov wrote: > > after upgrading from 3.4.0 to 3.5.0-rc5 on this powerpc machine, the > > following is printed during bootup: > > > > [ 18.630750] device fsid ce8c9df5-0a93-47c6-adf6-25084f352a4f devid 1 > > transid 11061 /dev/hda7 > > [ 18.637193] btrfs: disk space caching is enabled > > [ 18.706423] btrfs: no dev_stats entry found for device /dev/hda7 > > (devid 1) (OK on first mount after mkfs) > > > > The btrfs on hda7 has been created many months ago and has been mounted > > several times since then. Assuming "first mount after mkfs" does not apply > > here, is it then NOT OK that no dev_stats entry has been found? > > > > IOW: should I worry about this message? > > No, you should not. If this is your first mount after upgrading your > kernel to the one with btrfs dev stats feature, "first mount after mkfs" > sort of applies. OK, this is what I'd hoped for :-) Maybe the message should read "OK on first mount after mkfs or kernel upgrade" - but then again nobody else got worried, so the current message is OK, I guess. Thanks for replying, Christian. -- BOFH excuse #332: suboptimal routing experience -- 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: no dev_stats entry found / OK on first mount after mkfs
On Mon, Jul 02, 2012 at 02:46:11PM -0700, Christian Kujau wrote: > Hi, > > after upgrading from 3.4.0 to 3.5.0-rc5 on this powerpc machine, the > following is printed during bootup: > > [ 18.630750] device fsid ce8c9df5-0a93-47c6-adf6-25084f352a4f devid 1 > transid 11061 /dev/hda7 > [ 18.637193] btrfs: disk space caching is enabled > [ 18.706423] btrfs: no dev_stats entry found for device /dev/hda7 (devid > 1) (OK on first mount after mkfs) > > The btrfs on hda7 has been created many months ago and has been mounted > several times since then. Assuming "first mount after mkfs" does not apply > here, is it then NOT OK that no dev_stats entry has been found? > > IOW: should I worry about this message? No, you should not. If this is your first mount after upgrading your kernel to the one with btrfs dev stats feature, "first mount after mkfs" sort of applies. Thanks, Ilya -- 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
no dev_stats entry found / OK on first mount after mkfs
Hi, after upgrading from 3.4.0 to 3.5.0-rc5 on this powerpc machine, the following is printed during bootup: [ 18.630750] device fsid ce8c9df5-0a93-47c6-adf6-25084f352a4f devid 1 transid 11061 /dev/hda7 [ 18.637193] btrfs: disk space caching is enabled [ 18.706423] btrfs: no dev_stats entry found for device /dev/hda7 (devid 1) (OK on first mount after mkfs) The btrfs on hda7 has been created many months ago and has been mounted several times since then. Assuming "first mount after mkfs" does not apply here, is it then NOT OK that no dev_stats entry has been found? IOW: should I worry about this message? Thanks, Christian. -- BOFH excuse #313: your process is not ISO 9000 compliant -- 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: rework shrink_delalloc
So shrink_delalloc has grown all sorts of cruft over the years thanks to
many reworkings of how we track enospc. What happens now as we fill up the
disk is we will loop for freaking ever hoping to reclaim a arbitrary amount
of space of metadata, this was from when everybody flushed at the same time.
Now we only have people flushing one at a time. So instead of trying to
reclaim a huge amount of space, just try to flush a decent chunk of space,
and stop looping as soon as we have enough free space to satisfy our
reservation. This makes xfstests 224 go much faster. Thanks,
Signed-off-by: Josef Bacik
---
fs/btrfs/extent-tree.c | 81 ++-
1 files changed, 24 insertions(+), 57 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 5a1d9d2..e66967c 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -3585,89 +3585,58 @@ out:
/*
* shrink metadata reservation for delalloc
*/
-static int shrink_delalloc(struct btrfs_root *root, u64 to_reclaim,
- bool wait_ordered)
+static void shrink_delalloc(struct btrfs_root *root, u64 to_reclaim, u64 orig,
+ bool wait_ordered)
{
struct btrfs_block_rsv *block_rsv;
struct btrfs_space_info *space_info;
struct btrfs_trans_handle *trans;
- u64 reserved;
+ u64 delalloc_bytes;
u64 max_reclaim;
- u64 reclaimed = 0;
long time_left;
unsigned long nr_pages = (2 * 1024 * 1024) >> PAGE_CACHE_SHIFT;
int loops = 0;
- unsigned long progress;
trans = (struct btrfs_trans_handle *)current->journal_info;
block_rsv = &root->fs_info->delalloc_block_rsv;
space_info = block_rsv->space_info;
smp_mb();
- reserved = space_info->bytes_may_use;
- progress = space_info->reservation_progress;
-
- if (reserved == 0)
- return 0;
-
- smp_mb();
- if (root->fs_info->delalloc_bytes == 0) {
+ delalloc_bytes = root->fs_info->delalloc_bytes;
+ if (delalloc_bytes == 0) {
if (trans)
- return 0;
+ return;
btrfs_wait_ordered_extents(root, 0, 0);
- return 0;
+ return;
}
- max_reclaim = min(reserved, to_reclaim);
- nr_pages = max_t(unsigned long, nr_pages,
-max_reclaim >> PAGE_CACHE_SHIFT);
- while (loops < 1024) {
- /* have the flusher threads jump in and do some IO */
- smp_mb();
- nr_pages = min_t(unsigned long, nr_pages,
- root->fs_info->delalloc_bytes >> PAGE_CACHE_SHIFT);
+ while (delalloc_bytes && loops < 3) {
+ max_reclaim = min(delalloc_bytes, to_reclaim);
+ nr_pages = max_reclaim >> PAGE_CACHE_SHIFT;
writeback_inodes_sb_nr_if_idle(root->fs_info->sb, nr_pages,
- WB_REASON_FS_FREE_SPACE);
+ WB_REASON_FS_FREE_SPACE);
spin_lock(&space_info->lock);
- if (reserved > space_info->bytes_may_use)
- reclaimed += reserved - space_info->bytes_may_use;
- reserved = space_info->bytes_may_use;
+ if (space_info->bytes_used + space_info->bytes_reserved +
+ space_info->bytes_pinned + space_info->bytes_readonly +
+ space_info->bytes_may_use + orig <=
+ space_info->total_bytes) {
+ spin_unlock(&space_info->lock);
+ break;
+ }
spin_unlock(&space_info->lock);
loops++;
-
- if (reserved == 0 || reclaimed >= max_reclaim)
- break;
-
- if (trans && trans->transaction->blocked)
- return -EAGAIN;
-
if (wait_ordered && !trans) {
btrfs_wait_ordered_extents(root, 0, 0);
} else {
- time_left = schedule_timeout_interruptible(1);
-
- /* We were interrupted, exit */
+ time_left = schedule_timeout_killable(1);
if (time_left)
break;
}
-
- /* we've kicked the IO a few times, if anything has been freed,
-* exit. There is no sense in looping here for a long time
-* when we really need to commit the transaction, or there are
-* just too many writers without enough free space
-*/
-
- if (loops > 3) {
- smp_mb();
- if (progress != space_info->reservation_progress)
- break;
- }
-
+ smp_mb();
+ delall
Re: Please hammer my for-linus branch
On Sat, Jun 30, 2012 at 09:22:59PM -0400, Chris Mason wrote: > Hi everyone, > > I've got a nice set of fixes from Josef, Jan, Ilya and others in my > for-linus branch: > > git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus > > Some of the changes are fixes for the tree logging code, so I ran some > extra crash runs against them Friday night. > > I ended up with a new crash in the tree log directory deletion replay > code, so I didn't send out the pull request to Linus. > > It isn't clear yet if the new crash is because I was testing differently > or if it is a regression. I'm nailing it down this weekend, but please > give my for-linus a shot. Ok, I've just rebased for-linus. I've dropped Josef's enospc patch, which should fix the regression Dave hit. I've also added a fix for my log replay crash, which was definitely an old bug. The delayed directory operations were queuing up the changes made during replay, and it was confusing the replay code. Looks like there's a fix pending from Liu Bo, but I'll let Daniel test that before pulling it in as well. Thanks everyone. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Long btrfs hangs during suspend to RAM / BTRFS warning (device dm-0): Aborting unused transaction
On Fri, Jun 29, 2012 at 05:36:24AM -0700, Marc MERLIN wrote: > On Tue, Jun 26, 2012 at 10:20:12PM -0700, Marc MERLIN wrote: > > On Tue, Jun 26, 2012 at 06:38:18PM -0700, Marc MERLIN wrote: > > > Now, I'm also seeing these below and I have this again (86% CPU): > > > 6076 root 20 0 000 R 86 0.0 29:40.11 > > > btrfs-delalloc- > > > > > > How bad is it, doctor? I think I'll be going back to 3.2.16 for now > > > though. > > I reverted to 3.2.16 and haven't had further problems after dropping the > current snapshot that was corrupted in various ways. > > Now, I'm not sure when I should upgrade anymore since I haven't heard of > any fixes for what I saw. > Assuming I go forward again, is there something else I could have > provided to help debug? Mmmh, ok. I understand that this code comes with no guarantees, and I have backups, but I'm reporting a problem that lead to corruption (I had multiple files that were corrupted in my latest snapshot and I had to drop it and revert to an older snapshot and then out of fear for 3.4.4, went back to 3.2.16). I didn't see any problems with 3.2.16 (doesn't mean there weren't any, just that I didn't see any). Since my filesystem was a bit full, and that triggers problems with btrfs, I freed up 70GB gandalfthegreat:~# btrfs fi show Label: 'btrfs_pool1' uuid: 873d526c-e911-4234-af1b-239889cd143d Total devices 1 FS bytes used 163.01GB devid1 size 231.02GB used 231.02GB path /dev/dm-0 I rebooted with 3.4.4 and started copying data, and for now I've gotten this: kernel: [ 832.108558] btrfs no csum found for inode 3896855 start 0 kernel: [ 832.108873] btrfs csum failed ino 3896855 off 0 csum 1150320628 private 0 How bad is this? More generally, what was missing from my previous report (I gave all the sysrq I could output) that no one seemed to be able to use it? Thanks, Marc > > Back to 3.2.16, I'm now seeing this: > > [ 840.516733] INFO: task VirtualBox:6818 blocked for more than 120 seconds. > > [ 840.516735] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > > this message. > > [ 840.516736] VirtualBox D 8801fd134080 0 6818 6758 > > 0x0080 > > [ 840.516740] 8801fd134080 0086 0050 > > 880202e7f100 > > [ 840.516744] 00013580 8801c6f0dfd8 8801c6f0dfd8 > > 8801fd134080 > > [ 840.516748] 8801c6f0da68 8801c6f0da68 88020a4e22f0 > > 88023bc13e08 > > [ 840.516752] Call Trace: > > [ 840.516755] [] ? __lock_page+0x66/0x66 > > [ 840.516758] [] ? io_schedule+0x58/0x6f > > [ 840.516761] [] ? sleep_on_page+0x6/0xa > > [ 840.516764] [] ? __wait_on_bit_lock+0x3c/0x85 > > [ 840.516767] [] ? __lock_page+0x61/0x66 > > [ 840.516770] [] ? autoremove_wake_function+0x2a/0x2a > > [ 840.516785] [] ? > > extent_write_cache_pages.isra.13.constprop.22+0xf6/0x278 [btrfs] > > [ 840.516789] [] ? __cache_free.isra.40+0x19/0x1a7 > > [ 840.516792] [] ? sub_preempt_count+0x83/0x94 > > [ 840.516795] [] ? _raw_spin_unlock+0x24/0x30 > > [ 840.516811] [] ? extent_writepages+0x40/0x57 [btrfs] > > [ 840.516826] [] ? __btrfs_buffered_write+0x2bb/0x2dc > > [btrfs] > > [ 840.516841] [] ? > > uncompress_inline.isra.44+0x116/0x116 [btrfs] > > [ 840.516844] [] ? __filemap_fdatawrite_range+0x4b/0x50 > > [ 840.516847] [] ? > > filemap_write_and_wait_range+0x25/0x4d > > [ 840.516863] [] ? btrfs_file_aio_write+0x34e/0x490 > > [btrfs] > > [ 840.516866] [] ? get_parent_ip+0x9/0x1b > > [ 840.516882] [] ? __btrfs_buffered_write+0x2dc/0x2dc > > [btrfs] > > [ 840.516886] [] ? aio_rw_vect_retry+0x70/0x18e > > [ 840.516888] [] ? aio_fsync+0x22/0x22 > > [ 840.516891] [] ? aio_run_iocb+0x72/0x11c > > [ 840.516894] [] ? do_io_submit+0x6a4/0x7f9 > > [ 840.516898] [] ? system_call_fastpath+0x16/0x1b > > [ 1187.553635] btrfs: unlinked 8 orphans > > [ 3810.200064] e1000e :00:19.0: BAR 0: set to [mem > > 0xfc00-0xfc01] (PCI address [0xfc00-0xfc01]) > > [ 3810.200071] e1000e :00:19.0: BAR 1: set to [mem > > 0xfc025000-0xfc025fff] (PCI address [0xfc025000-0xfc025fff]) > > [ 3810.200076] e1000e :00:19.0: BAR 2: set to [io 0x1840-0x185f] (PCI > > address [0x1840-0x185f]) > > [ 3810.200093] e1000e :00:19.0: restoring config space at offset 0xf > > (was 0x100, writing 0x10b) > > [ 3810.200115] e1000e :00:19.0: restoring config space at offset 0x1 > > (was 0x10, writing 0x100107) > > [ 3810.200147] e1000e :00:19.0: PME# disabled > > [ 3810.200224] e1000e :00:19.0: irq 45 for MSI/MSI-X > > [ 4671.144685] iwlwifi :03:00.0: Tx aggregation enabled on ra = > > 2c:b0:5d:3c:7d:f1 tid = 1 > > [ 4799.384107] btrfs: unlinked 8 orphans > > [ 8436.512513] btrfs: unlinked 7 orphans > > [11350.749850] btrfs no csum found for inode 3909426 start 0 > > [11350.750697] btrfs csum failed ino 3909426 off 0 csum 1419704114 private 0 > > [11652.088805] btrfs no csum found for inode 391084
Testing permanent IO errors with btrfs
Hi everybody,
I am interested to test how btrfs behaves when the underlying block
device starts returning permanent IO errors. To test this, I set up a
linear device-mapper, mapped to the block device and start IOs. At
some point, I switch the device-mapper's table to "error" table (using
"dmsetup reload" and "dmsetup resume").
With older version of btrfs, I experienced kernel panics and sometimes
the IO processes would not terminate.
Today I tested with
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git up
to commit 782b7bca60c5021213e87ab26bbf94deb7654b62 (Merge branch
'for-chris' of git://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next
into for-linus). Things look better - kernel issued a warning about
aborting the transaction, and all IO processes exited with error.
However, after I unmounted (got some kernel warnings on unmount) and
mounted again, mount failed. Using btrfs-debug-tree, I followed the
__open_ctree_fd() path and discovered that:
Problem 1: superblock tells transaction id (13) higher than the chunk
tree root (5). (The chunk tree itself has only one leaf, which is also
the root.)
Problem 2: when trying to read the block of the root of tree roots
(read_tree_block()), using bytenr stored at superblock->root and the
chunk tree (with low transaction id) to map the block, brings
corrupted nodes from both locations (DUP).
At this point btrfs-debug-tree aborts, because the root of tree roots
is not available.
Below is some information, pls let me know if any additional info is needed.
Thanks,
Alex.
The superblock structure:
$11 = {csum = "Ø\017\336", '\000' , fsid =
"??CC\330\344M\327\272\237\003\363\065\266\274", , bytenr = 65536, flags = 1, magic = 5575266562640200287,
generation = 13, root = 29515776, chunk_root = 20971520, log_root = 0,
log_root_transid = 0, total_bytes = 21474836480, bytes_used =
3674767360, root_dir_objectid = 6, num_devices = 1, sectorsize = 4096,
nodesize = 4096, leafsize = 4096, stripesize = 4096,
sys_chunk_array_size = 226, chunk_root_generation = 13, compat_flags =
0, compat_ro_flags = 0, incompat_flags = 1, csum_type = 0, root_level
= 0 '\000', chunk_root_level = 0 '\000', log_root_level = 0 '\000',
dev_item = {devid = 1, total_bytes = 21474836480, bytes_used =
7553941504, io_align = 4096, io_width = 4096, sector_size = 4096, type
= 0, generation = 0, start_offset = 4294967312, dev_group = 0,
seek_speed = 1 '\001', bandwidth = 0 '\000', uuid =
"\206\201\355\"\311\330L\234\221\305\016d\362\241\276", , fsid =
"??CC\330\344M\327\272\237\003\363\065\266\274", }, label = '\000' , cache_generation = 0,
reserved = {0 }, sys_chunk_array =
"\000\001\000\000\000\000\000\000\344\000\000\000\000\000\000\000\000\000\000@\000\000\000\000\000\002\000\000\000\000\000\000\000\000\000\001\000\000\000\000\000\002\000\000\000\000\000\000\000\000\020\000\000\000\020\000\000\000\020\000\000\001\000\000\000\001",
'\000' "\206,
\201\355\"\311\330L\234\221\305\016d\362\241\276\356\000\001\000\000\000\000\000\000\344\000\000@\001\000\000\000\000\000\000\200\000\000\000\000\000\002\000\000\000\000\000\000\000\000\000\001\000\000\000\000\000\"\000\000\000\000\000\000\000\000\000\001\000\000\000\001\000\000\020\000\000\002\000\000\000\001\000\000\000\000\000\000\000\000\000@\001\000\000\000\000\206\201\355\"\311\330L\234\221\305\016d\362\241\276\356\001\000\000\000\000\000\000\000\000\000\300\001\000\000\000\000\206\201\355\"\311\330L\234\221\305\016d\362\241\276\356",
'\000' , super_roots = {{tree_root = 29425664,
tree_root_gen = 12, chunk_root = 20975616, chunk_root_gen = 11,
extent_root = 29417472, extent_root_gen = 12, fs_root = 29429760,
fs_root_gen = 13, dev_root = 29372416, dev_root_gen = 11, csum_root =
29376512, csum_root_gen = 5, total_bytes = 21474836480, bytes_used =
2252435456, num_devices = 1, unsed_64 = {0, 0, 0, 0}, tree_root_level
= 0 '\000', chunk_root_level = 0 '\000', extent_root_level = 0 '\000',
fs_root_level = 1 '\001', dev_root_level = 0 '\000', csum_root_level =
0 '\000', unused_8 = "\000\000\000\000\000\000\000\000\000"},
{tree_root = 29515776, tree_root_gen = 13, chunk_root = 20971520,
chunk_root_gen = 13, extent_root = 29507584, extent_root_gen = 13,
fs_root = 29519872, fs_root_gen = 14, dev_root = 29503488,
dev_root_gen = 13, csum_root = 29376512, csum_root_gen = 5,
total_bytes = 21474836480, bytes_used = 3674767360, num_devices = 1,
unsed_64 = {0, 0, 0, 0}, tree_root_level = 0 '\000', chunk_root_level
= 0 '\000', extent_root_level = 1 '\001', fs_root_level = 1 '\001',
dev_root_level = 0 '\000', csum_root_level = 0 '\000', unused_8 =
"\000\000\000\000\000\000\000\000\000"}, {tree_root = 29405184,
tree_root_gen = 10, chunk_root = 20971520, chunk_root_gen = 5,
extent_root = 29409280, extent_root_gen = 10, fs_root = 29360128,
fs_root_gen = 5, dev_root = 29392896, dev_root_gen = 8, csum_root =
29376512, csum_root_gen = 5, total_bytes = 21474836480, bytes_used =
28672, num_devices = 1, unsed_64 = {0, 0, 0, 0}, tree_root_level
= 0 '\000
Re: Btrfs RAID space utilization and bitrot reconstruction
Am Sonntag, 1. Juli 2012 schrieb Waxhead: > As far as I understand btrfs stores all data in huge chunks that are > striped, mirrored or "raid5/6'ed" throughout all the disks added to > the filesystem/volume. Not through all disks. At least not with the current RAID-1 implementation. It stores two copies of a chunk, no matter how many drives you use. Rest see Hugo´s answer. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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 directories in /
Am Sonntag, 1. Juli 2012 schrieb Markus Rothe: > Hello, Hi! > I am running btrfs for a few months now. I just realized that I have a > few strange directories in / > > % ls / -1 > ? > ???J?? > QӇ?? > PL > PR This might be a corrupted filesystem. Can you show ls -l / If size is ? or permissions then its pretty clear that it is. > Is this a known problem? I have absolutely no idea where these > directories come from. Anything in dmesg when you try to access any of these? Then standard question: Which kernel? Or try to btrfsck the fs using newest btrfs-tools. Do this with a copy of the device or make sure that your backup is good before. Thats so far from a users view. A developer might have some more tricks for you. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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: xfstests/224 lockup/slowdown (was: Please hammer my for-linus branch)
On Mon, Jul 02, 2012 at 04:34:53PM +0200, David Sterba wrote: > Bisection in progress. commit cae76522b19735c576803bec273f49062aa418ab Author: Josef Bacik Date: Thu Jun 21 14:05:49 2012 -0400 Btrfs: flush delayed inodes if we're short on space Those crazy gentoo guys have been complaining about ENOSPC errors on their portage volumes. This is because doing things like untar tends to create lots of new files which will soak up all the reservation space in the delayed inodes. Usually this gets papered over by the fact that we will try and commit the transaction, however if this happens in the wrong spot or we choose not to commit the transaction you will be screwed. So add the ability to expclitly flush delayed inodes to free up space. Please test this out guys to make sure it works since as usual I cannot reproduce. Thanks, -- 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: Feature request: true RAID-1 mode
On 06/25/2012 04:00 PM, H. Peter Anvin wrote: I am aware of that, and it is not a problem... the one-device bootloader can find out *which* disk it is talking to by comparing uuids, and the btrfs data structures will tell it how to find the data on that specific disk. It does of course mean the bootloader needs to be aware of the multidisk nature of btrfs, but that isn't a problem in itself. So, also, let me address the question why we should care about a one-device bootloader. It is quite common, especially in fileservers, for a subset of the boot devices to be inaccessible by the firmware, due to bugs, boot time concerns (spinning up all the media in the firmware is SLOW) or just plain lack of support of plug-in cards. As such, the reliable thing to do is to make sure that any disk being seen is enough to bring up the system; since this is such a small amount of data with modern standards, there is just no reason to do anything less robust. Once the kernel comes up it has all the device drivers, of course. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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: kmem_cache_destroy called for cache that still has objects
> I print the insteresting part of syslog below. > > I mount the disk with > mount -t btrfs -o compress,noatime,nodiratime,noacl,noexec,nosuid /dev/sdb1 > /usb > > The error parts in the syslog come from the the mistaken > "mount /usb" and the line > /dev/sdb1 /usbauto > defaults,noauto,noatime,nodiratime,users,noexec,nosuid,nodev,nobarrier,noauto_da_alloc,data=writeback > 0 0 > in fstab. I could not see other errors. > > Regards, > Martin > > > Jul 2 12:33:57 zertz kernel: sd 10:0:0:0: [sdb] Attached SCSI disk > Jul 2 12:33:59 zertz kernel: Btrfs loaded > Jul 2 12:33:59 zertz kernel: device fsid > e8f96f55-a297-4bb5-8e8e-2dbf7db7e7af devid 1 transid 2627 /dev/sdb1 > Jul 2 12:33:59 zertz kernel: btrfs: turning off barriers > Jul 2 12:33:59 zertz kernel: btrfs: unrecognized mount option > 'noauto_da_alloc' > Jul 2 12:33:59 zertz kernel: btrfs: open_ctree failed > Jul 2 12:34:07 zertz kernel: device fsid > e8f96f55-a297-4bb5-8e8e-2dbf7db7e7af devid 1 transid 2627 /dev/sdb1 > Jul 2 12:34:07 zertz kernel: btrfs: use zlib compression > Jul 2 12:34:07 zertz kernel: btrfs: disk space caching is enabled > Jul 2 12:34:07 zertz kernel: btrfs: bdev /dev/sdb1 errs: wr 0, rd 0, flush > 0, corrupt 0, gen 0 > Jul 2 12:35:01 zertz /USR/SBIN/CRON[8308]: (root) CMD (zanacron) > Jul 2 12:35:01 zertz zanacron[8309](root): zanacron > Jul 2 12:35:01 zertz zanacron[8309](root): runs zanacron daily_online in 2 > minutes > Jul 2 12:36:23 zertz kernel: Btrfs loaded > Jul 2 12:36:23 zertz kernel: device fsid > e8f96f55-a297-4bb5-8e8e-2dbf7db7e7af devid 1 transid 2635 /dev/sdb1 > Jul 2 12:36:23 zertz kernel: btrfs: use zlib compression > Jul 2 12:36:23 zertz kernel: btrfs: disk space caching is enabled > Jul 2 12:36:23 zertz kernel: btrfs: bdev /dev/sdb1 errs: wr 0, rd 0, flush > 0, corrupt 0, gen 0 > Jul 2 12:37:00 zertz zanacron[8421](root): zanacron daily_online > Jul 2 12:37:00 zertz zanacron[8421](root): runs /bin/run-parts --report > /usr/local/etc/cron/cron.daily/online > Jul 2 12:43:25 zertz kernel: > = > Jul 2 12:43:25 zertz kernel: BUG btrfs_transaction_cache (Tainted: G > W ): Objects remaining on kmem_cache_close() > Jul 2 12:43:25 zertz kernel: > - > Jul 2 12:43:25 zertz kernel: > Jul 2 12:43:25 zertz kernel: INFO: Slab 0xea1c7580 objects=27 used=1 > fp=0x8800071d7e10 flags=0x40004080 > Jul 2 12:43:25 zertz kernel: Pid: 8613, comm: modprobe Tainted: GW > 3.5.0-rc4+ #278 > Jul 2 12:43:25 zertz kernel: Call Trace: > Jul 2 12:43:25 zertz kernel: [] ? slab_err+0xb1/0xd3 > Jul 2 12:43:25 zertz kernel: [] ? > unfreeze_partials+0x1b7/0x1b7 > Jul 2 12:43:25 zertz kernel: [] ? > ksm_migrate_page+0x2f/0x2f > Jul 2 12:43:25 zertz kernel: [] ? free_one_page+0x15c/0x20a > Jul 2 12:43:25 zertz kernel: [] ? __kmalloc+0x43/0x129 > Jul 2 12:43:25 zertz kernel: [] ? > kmem_cache_destroy+0x146/0x2a3 > Jul 2 12:43:25 zertz kernel: [] ? > btrfs_destroy_cachep+0x34/0x59 [btrfs] > Jul 2 12:43:25 zertz kernel: [] ? > btrfs_log_inode+0x448/0x448 [btrfs] > Jul 2 12:43:25 zertz kernel: [] ? > sys_delete_module+0x1ca/0x24e > Jul 2 12:43:25 zertz kernel: [] ? > mntput_no_expire+0x13/0x11c > Jul 2 12:43:25 zertz kernel: [] ? filp_close+0x56/0x5d > Jul 2 12:43:25 zertz kernel: [] ? > system_call_fastpath+0x16/0x1b > Jul 2 12:43:25 zertz kernel: INFO: Object 0x8800071d6250 @offset=592 > Jul 2 12:43:25 zertz kernel: SLUB btrfs_transaction_cache: > kmem_cache_destroy called for cache that still has objects. > Jul 2 12:43:25 zertz kernel: Pid: 8613, comm: modprobe Tainted: GW > 3.5.0-rc4+ #278 > Jul 2 12:43:25 zertz kernel: Call Trace: > Jul 2 12:43:25 zertz kernel: [] ? > kmem_cache_destroy+0x292/0x2a3 > Jul 2 12:43:25 zertz kernel: [] ? > btrfs_destroy_cachep+0x34/0x59 [btrfs] > Jul 2 12:43:25 zertz kernel: [] ? > btrfs_log_inode+0x448/0x448 [btrfs] > Jul 2 12:43:25 zertz kernel: [] ? exit_btrfs_fs+0x6/0x36 > [btrfs] > Jul 2 12:43:25 zertz kernel: [] ? > btrfs_log_inode+0x448/0x448 [btrfs] > Jul 2 12:43:25 zertz kernel: [] ? > sys_delete_module+0x1ca/0x24e > Jul 2 12:43:25 zertz kernel: [] ? > mntput_no_expire+0x13/0x11c > Jul 2 12:43:25 zertz kernel: [] ? filp_close+0x56/0x5d > Jul 2 12:43:25 zertz kernel: [] ? > system_call_fastpath+0x16/0x1b > Jul 2 12:43:52 zertz kernel: Btrfs loaded > Jul 2 12:43:52 zertz kernel: device fsid > e8f96f55-a297-4bb5-8e8e-2dbf7db7e7af devid 1 transid 2639 /dev/sdb1 > Jul 2 12:43:52 zertz kernel: btrfs: use zlib compression > Jul 2 12:43:52 zertz kernel: btrfs: disk space caching is enabled > Jul 2 12:43:52 zertz kernel: btrfs: bdev /dev/sdb1 errs: wr 0, rd 0, flush > 0, corrupt 0, gen 0 > ###
Re: xfstests/224 lockup/slowdown (was: Please hammer my for-linus branch)
On Mon, Jul 02, 2012 at 04:10:52PM +0200, David Sterba wrote: > Finishing this report anyway, and will redo the tests again. > > Looking again into the logs, the first process snapshot (only D-state > processes) is much longer than process snapshot of containing all, > unfortuntelly I don't have timestamps recorded, but this suggests that it's > very slowly going on, so slowly that I considered it stalled looking at the > io graphs. Fresh build, reboot, and single xfstests/224 run: during first ~20 seconds, there's high write activity, ie. file setup, then it goes to a "few tens-to-hundreds of KB every 4 seconds". Cpu is idle, sample output from dstat: total-cpu-usage --dsk/sda9- ---system-- usr sys idl wai hiq siq| read writ| int csw 1 1 99 0 0 0| 0 0 | 923 1856 0 1 98 0 1 0| 0 8192B| 904 2796 0 1 99 0 0 0| 0 0 | 945 1914 1 1 98 0 0 0| 0 0 | 899 1849 1 1 98 0 0 1| 0 0 | 906 1848 0 3 97 0 0 0| 020k| 901 3740 0 0 100 0 0 0| 0 0 | 905 1851 1 1 98 0 0 1| 0 0 | 946 1917 0 1 99 0 0 0| 0 0 | 904 1858 0 1 99 0 0 0| 0 8192B| 907 2805 1 1 98 0 0 1| 0 0 | 891 1836 0 1 99 0 0 0| 0 0 | 900 1847 0 1 99 0 0 0| 0 0 | 940 1905 1 4 95 0 0 0| 032k| 904 5153 1 2 97 0 0 0| 036k| 913 4240 0 1 99 0 0 0| 0 0 | 907 1849 0 1 99 0 0 0| 0 0 | 908 1852 1 1 98 0 0 1| 0 0 | 933 1901 1 2 98 0 0 0| 0 8192B| 916 2808 0 1 99 0 0 0| 0 0 | 917 1843 0 1 99 0 0 1| 0 0 | 908 1844 1 1 99 0 0 0| 0 0 | 905 1860 0 5 95 0 0 0| 036k| 943 7565 1 1 99 0 0 0| 0 0 | 911 1861 0 1 99 0 0 0| 0 0 | 910 1852 1 1 98 0 0 0| 0 0 | 944 1878 1 2 97 0 0 1| 016k| 898 3753 0 9 87 4 0 1| 0 1020k|103511k 0 19 74 7 0 1| 0 2092k|305224k 0 1 99 0 0 0| 0 0 | 909 1851 1 1 98 0 0 1| 0 0 | 915 1856 1 1 99 0 0 0| 0 0 | 896 1847 0 2 98 0 0 0| 0 8192B| 931 2847 0 1 99 0 0 0| 0 0 | 899 1850 1 1 98 0 0 1| 0 0 | 896 1861 0 1 99 0 0 0| 0 0 | 911 1855 1 5 94 0 0 0| 028k| 891 6521 0 9 87 3 0 1| 0 1100k| 96311k 0 1 99 0 0 0| 0 0 | 905 1857 1 1 99 0 0 0| 0 0 | 895 1851 1 1 98 0 0 0| 0 0 | 911 1852 0 7 88 4 0 1| 0 700k| 911 8533 0 1 99 0 0 0| 0 0 | 940 1905 1 1 99 0 0 0| 0 0 | 912 1851 1 1 99 0 0 0| 0 0 | 895 1851 0 10 89 0 0 1| 0 100k| 91213k and repeats more or less the same. Bisection in progress. 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: xfstests/224 lockup/slowdown (was: Please hammer my for-linus branch)
Hi, I'm seeing a machine lockup in xfstests/224, logs attached. Friday's xfstests round with 3.5-rc4 was ok, all tests passed. The 'dd' processes are in D-state with this stacktraces 5597 pts/0D+ 0:00 dd status=noxfer if=/dev/zero of=/mnt/a2/testfile.8 bs=4k conv=notrunc [] reserve_metadata_bytes+0x33e/0x8f0 [btrfs] [] btrfs_delalloc_reserve_metadata+0x134/0x3b0 [btrfs] [] btrfs_delalloc_reserve_space+0x3b/0x60 [btrfs] [] __btrfs_buffered_write+0x17b/0x380 [btrfs] [] btrfs_file_aio_write+0x253/0x4e0 [btrfs] [] do_sync_write+0xe2/0x120 [] vfs_write+0xce/0x190 [] sys_write+0x54/0xa0 [] system_call_fastpath+0x16/0x1b [] 0x and (not sure if there are more) 5666 pts/0D+ 0:00 dd status=noxfer if=/dev/zero of=/mnt/a2/testfile.6 bs=4k conv=notrunc [] reserve_metadata_bytes+0x33e/0x8f0 [btrfs] [] btrfs_block_rsv_add+0x3a/0x60 [btrfs] [] start_transaction+0x26e/0x330 [btrfs] [] btrfs_start_transaction+0x13/0x20 [btrfs] [] btrfs_dirty_inode+0xb0/0xe0 [btrfs] [] btrfs_update_time+0xcd/0x180 [btrfs] [] btrfs_file_aio_write+0x1c8/0x4e0 [btrfs] [] do_sync_write+0xe2/0x120 [] vfs_write+0xce/0x190 [] sys_write+0x54/0xa0 [] system_call_fastpath+0x16/0x1b all btrfs kernel threads are idle. Mount options: -o space_cache Mkfs: fresh, default options # btrfs fi df /mnt/a2 System: total=4.00MiB, used=4.00KiB Data+Metadata: total=1020.00MiB, used=987.32MiB [meanwhile] While grabbing lockdep stats the test respawned 224 236s ...[14:57:42] [15:46:56] 2954s but there was no disk activity, I wonder if touching /proc/lockdep or /proc/lock_stat is affecting this. Finishing this report anyway, and will redo the tests again. Looking again into the logs, the first process snapshot (only D-state processes) is much longer than process snapshot of containing all, unfortuntelly I don't have timestamps recorded, but this suggests that it's very slowly going on, so slowly that I considered it stalled looking at the io graphs. david for-linus-hung-224-all.txt.gz Description: Binary data for-linus-hung-224-D.txt.gz Description: Binary data
Re: kmem_cache_destroy called for cache that still has objects
I print the insteresting part of syslog below. I mount the disk with mount -t btrfs -o compress,noatime,nodiratime,noacl,noexec,nosuid /dev/sdb1 /usb The error parts in the syslog come from the the mistaken "mount /usb" and the line /dev/sdb1 /usbauto defaults,noauto,noatime,nodiratime,users,noexec,nosuid,nodev,nobarrier,noauto_da_alloc,data=writeback 0 0 in fstab. I could not see other errors. Regards, Martin Jul 2 12:33:57 zertz kernel: sd 10:0:0:0: [sdb] Attached SCSI disk Jul 2 12:33:59 zertz kernel: Btrfs loaded Jul 2 12:33:59 zertz kernel: device fsid e8f96f55-a297-4bb5-8e8e-2dbf7db7e7af devid 1 transid 2627 /dev/sdb1 Jul 2 12:33:59 zertz kernel: btrfs: turning off barriers Jul 2 12:33:59 zertz kernel: btrfs: unrecognized mount option 'noauto_da_alloc' Jul 2 12:33:59 zertz kernel: btrfs: open_ctree failed Jul 2 12:34:07 zertz kernel: device fsid e8f96f55-a297-4bb5-8e8e-2dbf7db7e7af devid 1 transid 2627 /dev/sdb1 Jul 2 12:34:07 zertz kernel: btrfs: use zlib compression Jul 2 12:34:07 zertz kernel: btrfs: disk space caching is enabled Jul 2 12:34:07 zertz kernel: btrfs: bdev /dev/sdb1 errs: wr 0, rd 0, flush 0, corrupt 0, gen 0 Jul 2 12:35:01 zertz /USR/SBIN/CRON[8308]: (root) CMD (zanacron) Jul 2 12:35:01 zertz zanacron[8309](root): zanacron Jul 2 12:35:01 zertz zanacron[8309](root): runs zanacron daily_online in 2 minutes Jul 2 12:36:23 zertz kernel: Btrfs loaded Jul 2 12:36:23 zertz kernel: device fsid e8f96f55-a297-4bb5-8e8e-2dbf7db7e7af devid 1 transid 2635 /dev/sdb1 Jul 2 12:36:23 zertz kernel: btrfs: use zlib compression Jul 2 12:36:23 zertz kernel: btrfs: disk space caching is enabled Jul 2 12:36:23 zertz kernel: btrfs: bdev /dev/sdb1 errs: wr 0, rd 0, flush 0, corrupt 0, gen 0 Jul 2 12:37:00 zertz zanacron[8421](root): zanacron daily_online Jul 2 12:37:00 zertz zanacron[8421](root): runs /bin/run-parts --report /usr/local/etc/cron/cron.daily/online Jul 2 12:43:25 zertz kernel: = Jul 2 12:43:25 zertz kernel: BUG btrfs_transaction_cache (Tainted: GW ): Objects remaining on kmem_cache_close() Jul 2 12:43:25 zertz kernel: - Jul 2 12:43:25 zertz kernel: Jul 2 12:43:25 zertz kernel: INFO: Slab 0xea1c7580 objects=27 used=1 fp=0x8800071d7e10 flags=0x40004080 Jul 2 12:43:25 zertz kernel: Pid: 8613, comm: modprobe Tainted: GW 3.5.0-rc4+ #278 Jul 2 12:43:25 zertz kernel: Call Trace: Jul 2 12:43:25 zertz kernel: [] ? slab_err+0xb1/0xd3 Jul 2 12:43:25 zertz kernel: [] ? unfreeze_partials+0x1b7/0x1b7 Jul 2 12:43:25 zertz kernel: [] ? ksm_migrate_page+0x2f/0x2f Jul 2 12:43:25 zertz kernel: [] ? free_one_page+0x15c/0x20a Jul 2 12:43:25 zertz kernel: [] ? __kmalloc+0x43/0x129 Jul 2 12:43:25 zertz kernel: [] ? kmem_cache_destroy+0x146/0x2a3 Jul 2 12:43:25 zertz kernel: [] ? btrfs_destroy_cachep+0x34/0x59 [btrfs] Jul 2 12:43:25 zertz kernel: [] ? btrfs_log_inode+0x448/0x448 [btrfs] Jul 2 12:43:25 zertz kernel: [] ? sys_delete_module+0x1ca/0x24e Jul 2 12:43:25 zertz kernel: [] ? mntput_no_expire+0x13/0x11c Jul 2 12:43:25 zertz kernel: [] ? filp_close+0x56/0x5d Jul 2 12:43:25 zertz kernel: [] ? system_call_fastpath+0x16/0x1b Jul 2 12:43:25 zertz kernel: INFO: Object 0x8800071d6250 @offset=592 Jul 2 12:43:25 zertz kernel: SLUB btrfs_transaction_cache: kmem_cache_destroy called for cache that still has objects. Jul 2 12:43:25 zertz kernel: Pid: 8613, comm: modprobe Tainted: GW 3.5.0-rc4+ #278 Jul 2 12:43:25 zertz kernel: Call Trace: Jul 2 12:43:25 zertz kernel: [] ? kmem_cache_destroy+0x292/0x2a3 Jul 2 12:43:25 zertz kernel: [] ? btrfs_destroy_cachep+0x34/0x59 [btrfs] Jul 2 12:43:25 zertz kernel: [] ? btrfs_log_inode+0x448/0x448 [btrfs] Jul 2 12:43:25 zertz kernel: [] ? exit_btrfs_fs+0x6/0x36 [btrfs] Jul 2 12:43:25 zertz kernel: [] ? btrfs_log_inode+0x448/0x448 [btrfs] Jul 2 12:43:25 zertz kernel: [] ? sys_delete_module+0x1ca/0x24e Jul 2 12:43:25 zertz kernel: [] ? mntput_no_expire+0x13/0x11c Jul 2 12:43:25 zertz kernel: [] ? filp_close+0x56/0x5d Jul 2 12:43:25 zertz kernel: [] ? system_call_fastpath+0x16/0x1b Jul 2 12:43:52 zertz kernel: Btrfs loaded Jul 2 12:43:52 zertz kernel: device fsid e8f96f55-a297-4bb5-8e8e-2dbf7db7e7af devid 1 transid 2639 /dev/sdb1 Jul 2 12:43:52 zertz kernel: btrfs: use zlib compression Jul 2 12:43:52 zertz kernel: btrfs: disk space caching is enabled Jul 2 12:43:52 zertz kernel: btrfs: bdev /dev/sdb1 errs: wr 0, rd 0, flush 0, corrupt 0, gen 0 ### -- 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: Please hammer my for-linus branch
On Sun, Jul 01, 2012 at 09:35:01PM -0600, Daniel J Blueman wrote:
> > Hi everyone,
> >
> > I've got a nice set of fixes from Josef, Jan, Ilya and others in my
> > for-linus branch:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
> > for-linus
> >
> > Some of the changes are fixes for the tree logging code, so I ran some
> > extra crash runs against them Friday night.
> >
> > I ended up with a new crash in the tree log directory deletion replay
> > code, so I didn't send out the pull request to Linus.
> >
> > It isn't clear yet if the new crash is because I was testing differently
> > or if it is a regression. I'm nailing it down this weekend, but please
> > give my for-linus a shot.
>
> With this branch (3.4.0), my test has consistently been hitting the
> BUG_ON(owner < BTRFS_FIRST_FREE_OBJECTID) in
> insert_inline_extent_backref [1]. This is followed by a string of
> other issues [2] and a hard lockup, so I used netconsole to collect
> this.
>
> I'm preparing my btrfs test for xfstests integration, but can slip you
> it if interested. It hits this case in ~30s.
>
Can you apply this and capture the output, I have a feeling I know what this is.
Thanks,
Josef
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 5775dc4..917ea70 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -1766,7 +1766,13 @@ int insert_inline_extent_backref(struct
btrfs_trans_handle *trans,
bytenr, num_bytes, parent,
root_objectid, owner, offset, 1);
if (ret == 0) {
- BUG_ON(owner < BTRFS_FIRST_FREE_OBJECTID);
+ if (owner < BTRFS_FIRST_FREE_OBJECTID) {
+ printk(KERN_ERR "bad inline extent, bytenr=%Lu, "
+ "num_bytes=%Lu, parent=%Lu, root=%Lu, owner=%Lu"
+ ", offset=%Lu\n", bytenr, num_bytes, parent,
+ root_objectid, owner, offset);
+ BUG_ON(owner < BTRFS_FIRST_FREE_OBJECTID);
+ }
update_inline_extent_backref(trans, root, path, iref,
refs_to_add, extent_op);
} else if (ret == -ENOENT) {
--
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: fio reports data corruption with btrfs
On Mon, Jul 02, 2012 at 05:48:43AM -0600, Alex Lyakas wrote: > Hi Josef, > which branch from your (or another?) repo should I try this on: > Master, and make sure you've checked out a more recent fio from git to make sure it's not a bug in fio. Thanks, 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: kmem_cache_destroy called for cache that still has objects
On Mon, Jul 02, 2012 at 05:06:27AM -0600, Martin Ziegler wrote: > When I umounted my USB-disk today, I got the following > message: > > FSSync '/usb' > = > BUG btrfs_transaction_cache (Tainted: GW ): > Objects remaining on kmem_cache_close() > - > > INFO: Slab 0xea1c7580 objects=27 used=1 > fp=0x8800071d7e10 flags=0x40004080 > INFO: Object 0x8800071d6250 @offset=592 > SLUB btrfs_transaction_cache: kmem_cache_destroy called for > cache that still has objects. > > > This had no bad consequences (I hope), but may interest the > developers. The kernel is > > Linux zertz 3.5.0-rc4+ #278 SMP Thu Jun 28 21:17:37 CEST > 2012 x86_64 GNU/Linux. > Did you have an aborted transaction or anything, any other errors in your dmesg? Thanks, 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] Btrfs: fix dio write vs buffered read race V3
On Sun, Jul 01, 2012 at 04:34:44AM -0600, Miao Xie wrote:
> On Thu, 28 Jun 2012 09:09:04 -0400, Josef Bacik wrote:
> > fs/btrfs/file.c | 13
> > fs/btrfs/inode.c | 55
> > +
> > 2 files changed, 50 insertions(+), 18 deletions(-)
> >
> > diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
> > index 70dc8ca..9aa01ec 100644
> > --- a/fs/btrfs/file.c
> > +++ b/fs/btrfs/file.c
> > @@ -1334,7 +1334,6 @@ static ssize_t __btrfs_direct_write(struct kiocb
> > *iocb,
> > loff_t *ppos, size_t count, size_t ocount)
> > {
> > struct file *file = iocb->ki_filp;
> > - struct inode *inode = fdentry(file)->d_inode;
> > struct iov_iter i;
> > ssize_t written;
> > ssize_t written_buffered;
> > @@ -1344,18 +1343,6 @@ static ssize_t __btrfs_direct_write(struct kiocb
> > *iocb,
> > written = generic_file_direct_write(iocb, iov, &nr_segs, pos, ppos,
> > count, ocount);
> >
> > - /*
> > -* the generic O_DIRECT will update in-memory i_size after the
> > -* DIOs are done. But our endio handlers that update the on
> > -* disk i_size never update past the in memory i_size. So we
> > -* need one more update here to catch any additions to the
> > -* file
> > -*/
> > - if (inode->i_size != BTRFS_I(inode)->disk_i_size) {
> > - btrfs_ordered_update_i_size(inode, inode->i_size, NULL);
> > - mark_inode_dirty(inode);
> > - }
> > -
> > if (written < 0 || written == count)
> > return written;
>
> We should fall back the i_size in btrfs_direct_IO if we fails to do direct
> IO, right?
>
No we would have only updated the i_size in the case that we created new
extents, we won't have i_size beyond where we have data. Thanks,
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: fio reports data corruption with btrfs
Hi Josef, which branch from your (or another?) repo should I try this on: remotes/origin/HEAD -> origin/master remotes/origin/enospc3c78455 Btrfs: fall back to non-inline if we don't have enough space remotes/origin/for-chris 7e9ce65 Btrfs: hold a ref on the inode during writepages remotes/origin/master1573317 Btrfs: use helper function to simplify code Thanks, Alex. On Wed, Jun 27, 2012 at 4:46 PM, Josef Bacik wrote: > On Wed, Jun 27, 2012 at 02:15:59AM -0600, Alex Lyakas wrote: >> Hi Josef, >> I have rerun the test with btrfs-next master branch. fio reported >> mismatched blocks again. Mount options were the same (-o >> noatime,nodatacow). >> > > Ok I'll try running it again here locally, I didn't realize it was nodatacow. > In the meantime can you try a newer version of fio, I'm running > fio-2.0.6-1.fc18.x86_64 but I think git is even newer than that. Thanks, > > 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
kmem_cache_destroy called for cache that still has objects
When I umounted my USB-disk today, I got the following message: FSSync '/usb' = BUG btrfs_transaction_cache (Tainted: GW ): Objects remaining on kmem_cache_close() - INFO: Slab 0xea1c7580 objects=27 used=1 fp=0x8800071d7e10 flags=0x40004080 INFO: Object 0x8800071d6250 @offset=592 SLUB btrfs_transaction_cache: kmem_cache_destroy called for cache that still has objects. This had no bad consequences (I hope), but may interest the developers. The kernel is Linux zertz 3.5.0-rc4+ #278 SMP Thu Jun 28 21:17:37 CEST 2012 x86_64 GNU/Linux. Regards, Martin -- 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 1/3] Btrfs-progs: add support to set subvolume/snapshot readonly
On Mon, Jul 02, 2012 at 10:07:42AM +0800, Liu Bo wrote:
> On 06/29/2012 06:21 PM, Ilya Dryomov wrote:
>
> > On Fri, Jun 29, 2012 at 06:00:36PM +0800, Liu Bo wrote:
> >> Setting subvolume/snapshot readonly has been missing for a long time.
> >>
> >> With this patch, we can set a subvolume/snapshot readonly via:
> >>
> >> obtrfs subvolume set-ro
> >
> > Alexander's 'btrfs property' patches do exactly this, but in a much more
> > generic and extensible way. 'btrfs property' subgroup provides a
> > uniform interface for getting and setting properties of filesystem
> > objects in general, not only those of subvolumes and snapshots. It
> > provides a much better user interface, and it also allows us to easily
> > rethink kernel-user interface for generic get/set in future.
> >
>
>
> Thanks for the explanation!
>
> But I prefer keeping the current categories {subvolume,filesystem,device,...}:
>
> o Compatibility, we cannot remove the old commands until we make sure that no
> users will
> use them.
We are not going to remove old commands any time soon. However, adding
new ones that clearly fall into get/set category, is not a good idea.
Especially when there is a generic interface on its way.
>
> o We've three properties {default, readonly, lable}, is it worthy making
> another new interface?
It's not just about subvolumes. There will be a lot more properties on
the table as filesystem matures, for example device speeds, subvolume
profiles, quotas.
>
> o Current categories are clear and clean.
Once again, it's not just about subvolumes. Current categories are
indeed clear, but adding two commands for each non-trivial property that
comes up in future does not seem practical to me.
Thanks,
Ilya
--
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 2/3] Btrfs-progs: make get default report correctly
On Mon, Jul 02, 2012 at 09:39:45AM +0800, Liu Bo wrote: > On 06/29/2012 06:36 PM, Ilya Dryomov wrote: > > > On Fri, Jun 29, 2012 at 06:00:37PM +0800, Liu Bo wrote: > >> We have both set-default and get-default, but actually our get-default > >> does not show which one is the default one. > >> > >> This patch plus the kernel side patch fix this. > > > > Are you referring to the fact that get-default in Chris' btrfs-progs > > master lists all subvolumes instead of showing the default one? If so, > > I fixed that problem a while ago, patch is in Hugo's integration branch. > > > > > So can you please show me a link about your patch? I'm sorry, it turns out Hugo hasn't pushed it yet. Here is a link: http://thread.gmane.org/gmane.comp.file-systems.btrfs/16187/ Thanks, Ilya -- 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
Mounting subvolumes and FS-wide mount options?
Hello, Suppose I have in /etc/fstab: /dev/sda2 /mnt/p2 btrfs noatime 0 0 /dev/sda2 /home btrfs subvol=/home0 0 /dev/sda2 /srv btrfs subvol=/srv 0 0 Now I want to add mount options like "space_cache" and "inode_cache". As far as I understand these are FS-wide and not per subvolume. Also, changing them once the FS has been mounted on a later subvolume mount is not allowed (?). The question is, where to add them? a) to the first mount in the list? Counting on the fact that it will be mounted first (but it might be not). b) to all of them? But that's time consuming to duplicate identical options on each line and especially when editing them later. Also, should I duplicate options like "noatime" and other generic options also to all of the subvolume mounts? I feel this is not obvious, not well-documented, and generally feels messy, so until now I just avoided mounting individual subvolumes altogether, instead preferring to mount the FS itself once somewhere under /mnt, and then "mount --bind" stuff to final places where I needed it. -- With respect, Roman ~~~ "Stallman had a printer, with code he could not see. So he began to tinker, and set the software free." signature.asc Description: PGP signature
