Re: apt taints kernel - btrfs destroys inode
Adam Borowski posted on Sun, 08 May 2016 01:11:18 +0200 as excerpted: > Duncan wrote: >> > btrfs_destroy_inode > >> That's a known apparent false-positive warning on current 4.6-rc kernel >> btrfs. The destroy-inode bit is related to a file deletion happening >> in the normal order of things, where this warning code is run, and >> apparently triggers even under normal operations. > > Are you guys reasonably certain it's false-positive? I don't personally know. I'm just a btrfs user and list regular myself, not a dev, and I personally haven't seen this bug, but then my use-case doesn't require either snapshots or quotas, so I don't use either, and wouldn't be _expected_ to see this bug. But all reported evidence suggests that it's a false-positive, as even the people hitting it extremely frequently haven't seen any real problems from it. > If so, you _really_ > want to disable the warning for 4.6, less than a week from now. Any > reasonable user of a stable kernel who notices such a warning and stack > dumps will assume something is broken, rightfully panic and consider the > filesystem unsound. I can't disagree. But I'm a user, not a dev... However, based on my own tracking of pre-release kernels, reverts or (temporarily?) silenced warnings for exactly this sort of appeared-over- the-release-cycle issue that they had hoped to actually track down and fix during the cycle, but simply didn't get there in time, do tend to come in at about this time, as it becomes apparent the trace-down, fix, and full testing, simply can't be completed in the cycle in which the problem was introduced or at least exposed, so the wise action is to simply revert or paper over for at least the one release, with the appropriate fix very likely to then hit the next kernel, either the initial commit window, or in any case before rc3 or so when people like me often start testing. What worries me is that I've seen no on-list indication that this particular bug has been traced even to a point that a specific revert can be done, or alternatively, that there's enough code-level confidence that it's a false-positive to silence the warning. However, it should be noted that particularly if it's a simple revert, there may in fact be no such on-list discussion as there's not necessarily anything to discuss, only a final decision by the project lead (or occasionally Linus himself) to revert or simply let it ride. >> It's related to some btrfs feature (I think either snapshotting or >> quotas, but don't recall which) I don't use here so I don't seem the >> warnings, but there's several threads where people have reported the >> warnings, so it's apparently quite commonly triggered, but nobody has >> reported any further problems even where the warnings are coming in the >> hundreds due to their use-case, so as I said, apparently a >> false-positive induced by normal operations. > > A data point: I've been running for a week with this WARN_ON replaced by > a printk: > > --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -9258,7 +9258,8 @@ void > btrfs_destroy_inode(struct inode *inode) > WARN_ON(BTRFS_I(inode)->outstanding_extents); > WARN_ON(BTRFS_I(inode)->reserved_extents); > WARN_ON(BTRFS_I(inode)->delalloc_bytes); > - WARN_ON(BTRFS_I(inode)->csum_bytes); > + if (BTRFS_I(inode)->csum_bytes) > + printk("btrfs: btrfs_destroy_inode: WARN csum_bytes\n"); > WARN_ON(BTRFS_I(inode)->defrag_bytes); > > /* > > and no data loss or anything suspicious so far. This box has a SSD > (moderate use) and HDD (light use), no RAID, no quotas, compress=lzo, > many subvolumes, 20ish snapshots daily (mostly sbuild for Debian > packages). That's nearly identical to what others have noted, as well, thus my describing it as an apparent false-positive, because despite many triggered warnings among the several reporters, no tragedy has seemed to strike as a result. > [~]$ dmesg|grep btrfs_destroy_inode|wc -l > 50 > [~]$ uptime > 00:17:47 up 1 day, 18:44, 19 users, load average: 0.23, 0.35, 0.61 > [~]$ cat /proc/version > Linux version 4.6.0-rc6-debug+ (kilobyte@umbar) > (gcc version 6.1.1 20160430 (Debian 6.1.1-1) ) > #1 SMP Fri May 6 00:33:44 CEST 2016 > >> I'd expect the warning to be either fixed to only warn when there's an >> actual issue, or be silenced, by 4.6 release. > > In order to get to 4.6 such a commit would need to hit Linus about right > now... Agreed. (Matter of fact, I'm about to git pull and git log check what's new over the last couple days, as I write this, before I continue checking the new messages here. As you say, it's gotta be real soon now if it's going to happen. Maybe it's either in-kernel or at least in a list-announced pull ready for Linus as I write...) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [PATCH] btrfs-progs: udev: add rules for dm devices
06.05.2016 22:27, Jeff Mahoney пишет: > Systemd's btrfs rule runs btrfs dev ready on each device > as it's discovered. The btrfs command is executed as a builtin > command via an IMPORT{builtin} rule, which means it gets > executed at rule evaluation time, not rule execution time. That > means that the device mapper links haven't been setup yet and the only > nodes that can be depended upon are /dev/dm-#. That we see > /dev/mapper/name names in /proc/mounts is only because we replace the > device name we have cached with the one passed in via mount. If > we have a multi-device file system and the primary device is removed, > the remaining devices will show /dev/dm-#. In addition, if the And I still do not understand why it is bad while /dev/sd#n is good. > udev rule is executed again by someone generating a change event (e.g. > partprobe), the names are also replaced by the /dev/dm-# names. > > This patch adds a new rule that adds a run rule that calls btrfs dev > ready again using the device mapper links once they're created. > --- > 64-btrfs-dm.rules | 10 ++ > Makefile.in | 7 +++ > configure.ac | 2 ++ > 3 files changed, 19 insertions(+) > create mode 100644 64-btrfs-dm.rules > > diff --git a/64-btrfs-dm.rules b/64-btrfs-dm.rules > new file mode 100644 > index 000..bbe1c35 > --- /dev/null > +++ b/64-btrfs-dm.rules > @@ -0,0 +1,10 @@ > +SUBSYSTEM!="block", GOTO="btrfs_end" > +KERNEL!="dm-[0-9]*", GOTO="btrfs_end" > +ACTION!="add|change", GOTO="btrfs_end" > +ENV{ID_FS_TYPE}!="btrfs", GOTO="btrfs_end" > + > +# Once the device mapper symlink is created, tell btrfs about it > +# so we get the friendly name in /proc/mounts (and tools that read it) > +ENV{DM_NAME}=="?*", TEST=="/dev/mapper/$env{DM_NAME}", RUN{builtin}+="btrfs > ready /dev/mapper/$env{DM_NAME}" > + That won't work for the very first event (presumably "add"). /dev/mapper link is created only after all rules have been processed, so it will always evaluate to false. > +LABEL="btrfs_end" > diff --git a/Makefile.in b/Makefile.in > index 19697ff..d555f6a 100644 > --- a/Makefile.in > +++ b/Makefile.in > @@ -83,11 +83,15 @@ libbtrfs_headers = send-stream.h send-utils.h send.h > rbtree.h btrfs-list.h \ > extent_io.h ioctl.h ctree.h btrfsck.h version.h > TESTS = fsck-tests.sh convert-tests.sh > > +udev_rules = 64-btrfs-dm.rules > + > prefix ?= @prefix@ > exec_prefix = @exec_prefix@ > bindir = @bindir@ > libdir ?= @libdir@ > incdir = @includedir@/btrfs > +udevdir = @UDEVDIR@ > +udevruledir = ${udevdir}/rules.d > > ifeq ("$(origin V)", "command line") >BUILD_VERBOSE = $(V) > @@ -377,6 +381,9 @@ install: $(libs) $(progs_install) $(INSTALLDIRS) > cp -a $(lib_links) $(DESTDIR)$(libdir) > $(INSTALL) -m755 -d $(DESTDIR)$(incdir) > $(INSTALL) -m644 $(headers) $(DESTDIR)$(incdir) > +ifneq ($(udevdir), "") > + $(INSTALL) -m644 $(udev_rules) $(DESTDIR)$(udevruledir) > +endif > > install-static: $(progs_static) $(INSTALLDIRS) > for p in $(progs_static) ; do \ > diff --git a/configure.ac b/configure.ac > index fc343ea..4af7474 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -124,6 +124,8 @@ PKG_STATIC(UUID_LIBS_STATIC, [uuid]) > PKG_CHECK_MODULES(ZLIB, [zlib]) > PKG_STATIC(ZLIB_LIBS_STATIC, [zlib]) > > +PKG_CHECK_VAR([UDEVDIR], [udev], [udevdir]) > + > dnl lzo library does not provide pkg-config, let use classic way > AC_CHECK_LIB([lzo2], [lzo_version], [ > LZO2_LIBS="-llzo2" > -- 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-tools: missing device delete/remove cancel option on disk failure
On 07/05/16 10:39, g6094...@freenet.de wrote: > a brand new disk which has an upcounting raw error rate Note that is the "raw error rate". For a brand new disk being run for the first time at maximum data writes, the "raw error rate" may well be expected to increase. Hard disks deliberately make use of error correction for normal operation. More importantly, what do the other smart values show? For myself, my concern would only be raised for sector failures. And... A very good test for a new disk is to first run "badblocks" to test the disk surface. Read the man page first. (Hint: Non-destructive is slow, destructive write is fast...) Good luck, 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: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair
On Sat, May 7, 2016 at 9:45 AM, Niccolò Belli wrote: > btrfs + dmcrypt + compress=lzo + autodefrag = corruption at first boot > So discard is not the culprit. Will try to remove compress=lzo and > autodefrag and see if it still happens. You're making the troubleshooting unnecessarily difficult by continuing to use non-default options. *shrug* Every single layer you add complicates the setup and troubleshooting. Of course all of it should work together, many people do. But you're the one having the problem so in order to demonstrate whether this is a software bug or hardware problem, you need to test it with the most basic setup possible --> btrfs on plain partitions and default mount options. -- Chris Murphy -- 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: apt taints kernel - btrfs destroys inode
Duncan wrote: > > btrfs_destroy_inode > That's a known apparent false-positive warning on current 4.6-rc kernel > btrfs. The destroy-inode bit is related to a file deletion happening in > the normal order of things, where this warning code is run, and > apparently triggers even under normal operations. Are you guys reasonably certain it's false-positive? If so, you _really_ want to disable the warning for 4.6, less than a week from now. Any reasonable user of a stable kernel who notices such a warning and stack dumps will assume something is broken, rightfully panic and consider the filesystem unsound. > It's related to some btrfs feature (I think either snapshotting or > quotas, but don't recall which) I don't use here so I don't seem the > warnings, but there's several threads where people have reported the > warnings, so it's apparently quite commonly triggered, but nobody has > reported any further problems even where the warnings are coming in the > hundreds due to their use-case, so as I said, apparently a false-positive > induced by normal operations. A data point: I've been running for a week with this WARN_ON replaced by a printk: --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -9258,7 +9258,8 @@ void btrfs_destroy_inode(struct inode *inode) WARN_ON(BTRFS_I(inode)->outstanding_extents); WARN_ON(BTRFS_I(inode)->reserved_extents); WARN_ON(BTRFS_I(inode)->delalloc_bytes); - WARN_ON(BTRFS_I(inode)->csum_bytes); + if (BTRFS_I(inode)->csum_bytes) + printk("btrfs: btrfs_destroy_inode: WARN csum_bytes\n"); WARN_ON(BTRFS_I(inode)->defrag_bytes); /* and no data loss or anything suspicious so far. This box has a SSD (moderate use) and HDD (light use), no RAID, no quotas, compress=lzo, many subvolumes, 20ish snapshots daily (mostly sbuild for Debian packages). [~]$ dmesg|grep btrfs_destroy_inode|wc -l 50 [~]$ uptime 00:17:47 up 1 day, 18:44, 19 users, load average: 0.23, 0.35, 0.61 [~]$ cat /proc/version Linux version 4.6.0-rc6-debug+ (kilobyte@umbar) (gcc version 6.1.1 20160430 (Debian 6.1.1-1) ) #1 SMP Fri May 6 00:33:44 CEST 2016 > I'd expect the warning to be either fixed to only warn when there's an > actual issue, or be silenced, by 4.6 release. In order to get to 4.6 such a commit would need to hit Linus about right now... Meow! -- How to exploit the Bible for weight loss: Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat. -- 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
[PATHCH] add option to supress "At subvol …" message in btrfs send
Hello, btrfs send puts a “At subvol …” on stderr, which is very annoying in scripts, esp. cron-jobs. Piping stderr to /dev/null does suppress this message, but also error-messages which one would probably want to see. I added an option to not change the behavior of btrfs send and possibly break existing scripts, but moving this message to verbose would be O.K. for me too. diff -Naur btrfs-progs-4.4.1/cmds-send.c btrfs-progs-4.4.1-neu/cmds-send.c --- btrfs-progs-4.4.1/cmds-send.c 2016-02-26 18:22:09.0 +0100 +++ btrfs-progs-4.4.1-neu/cmds-send.c 2016-05-07 18:10:13.935853568 +0200 @@ -45,6 +45,7 @@ #include "send-utils.h" static int g_verbose = 0; +static int g_quiet = 0; struct btrfs_send { int send_fd; @@ -442,7 +443,7 @@ static const struct option long_options[] = { { "no-data", no_argument, NULL, GETOPT_VAL_SEND_NO_DATA } }; - int c = getopt_long(argc, argv, "vec:f:i:p:", long_options, NULL); + int c = getopt_long(argc, argv, "vec:f:i:p:q", long_options, NULL); if (c < 0) break; @@ -534,6 +535,9 @@ error("option -i was removed, use -c instead"); ret = 1; goto out; + case 'q': + g_quiet = 1; + break; case GETOPT_VAL_SEND_NO_DATA: send_flags |= BTRFS_SEND_FLAG_NO_FILE_DATA; break; @@ -642,7 +646,8 @@ free(subvol); subvol = argv[i]; - fprintf(stderr, "At subvol %s\n", subvol); + if (!g_quiet) + fprintf(stderr, "At subvol %s\n", subvol); subvol = realpath(subvol, NULL); if (!subvol) { @@ -737,5 +742,6 @@ " does not contain any file data and thus cannot be used", " to transfer changes. This mode is faster and useful to", " show the differences in metadata.", + "-q suppress 'At subvol' message on stderr", NULL }; diff -Naur btrfs-progs-4.4.1/Documentation/btrfs-send.asciidoc btrfs-progs-4.4.1-neu/Documentation/btrfs-send.asciidoc --- btrfs-progs-4.4.1/Documentation/btrfs-send.asciidoc 2016-02-26 18:22:09.0 +0100 +++ btrfs-progs-4.4.1-neu/Documentation/btrfs-send.asciidoc 2016-05-07 18:14:24.615712654 +0200 @@ -45,6 +45,8 @@ Send in NO_FILE_DATA mode. The output stream does not contain any file data and thus cannot be used to transfer changes. This mode is faster and useful to show the differences in metadata. +-q:: +Suppress "At subvol" message on stderr. EXIT STATUS --- MfG bmg -- „Des is völlig wurscht, was heut beschlos- | M G Berberich sen wird: I bin sowieso dagegn!“ | m...@m-berberich.de (SPD-Stadtrat Kurt Schindler; Regensburg) | -- 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 ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair
Il 2016-05-07 17:58 Clemens Eisserer ha scritto: Hi Niccolo, btrfs + dmcrypt + compress=lzo + autodefrag = corruption at first boot Just to be curious - couldn't it be a hardware issue? I use almost the same setup (compress-force=lzo instead of compress-force=lzo) on my laptop for 2-3 years and haven't experienced any issues since ~kernel-3.14 or so. Br, Clemens Eisserer Hi, Which kind of hardware issue? I did a full memtest86 check, a full smartmontools extended check and even a badblocks -wsv. If this is really an hardware issue that we can identify I would be more than happy because Dell will replace my laptop and this nightmare will be finally over. I'm open to suggestions. Niccolò -- 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 ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair
Hi Niccolo, > btrfs + dmcrypt + compress=lzo + autodefrag = corruption at first boot Just to be curious - couldn't it be a hardware issue? I use almost the same setup (compress-force=lzo instead of compress-force=lzo) on my laptop for 2-3 years and haven't experienced any issues since ~kernel-3.14 or so. Br, Clemens Eisserer 2016-05-07 17:45 GMT+02:00 Niccolò Belli : > btrfs + dmcrypt + compress=lzo + autodefrag = corruption at first boot > So discard is not the culprit. Will try to remove compress=lzo and > autodefrag and see if it still happens. > > [ 748.224346] BTRFS error (device dm-0): memmove bogus src_offset 5431 move > len 4294962894 len 16384 > [ 748.226206] [ cut here ] > [ 748.227831] kernel BUG at fs/btrfs/extent_io.c:5723! > [ 748.229498] invalid opcode: [#1] PREEMPT SMP > [ 748.231161] Modules linked in: ext4 mbcache jbd2 nls_iso8859_1 nls_cp437 > vfat fat snd_hda_codec_hdmi dell_laptop dcdbas dell_wmi iTCO_wdt > iTCO_vendor_support intel_rapl x86_pkg_temp_thermal intel_powerclamp > coretemp kvm_intel arc4 kvm irqbypass psmouse serio_raw pcspkr elan_i2c > snd_soc_ssm4567 snd_soc_rt286 snd_soc_rl6347a snd_soc_core i2c_hid iwlmvm > snd_compress snd_pcm_dmaengine ac97_bus mac80211 uvcvideo videobuf2_vmalloc > btusb videobuf2_memops cdc_ether btrtl usbnet iwlwifi btbcm videobuf2_v4l2 > btintel intel_pch_thermal videobuf2_core i2c_i801 videodev r8152 rtsx_pci_ms > cfg80211 bluetooth visor media mii memstick joydev evdev mousedev input_leds > rfkill mac_hid crc16 i915 fan thermal wmi dw_dmac int3403_thermal video > dw_dmac_core drm_kms_helper snd_soc_sst_acpi i2c_designware_platform > snd_soc_sst_match > [ 748.237203] snd_hda_intel 8250_dw i2c_designware_core gpio_lynxpoint > spi_pxa2xx_platform drm int3402_thermal snd_hda_codec battery tpm_crb > intel_hid snd_hda_core sparse_keymap fjes snd_hwdep int3400_thermal > acpi_thermal_rel tpm_tis snd_pcm intel_gtt tpm acpi_als syscopyarea > sysfillrect snd_timer sysimgblt fb_sys_fops mei_me i2c_algo_bit > processor_thermal_device kfifo_buf processor snd industrialio acpi_pad ac > int340x_thermal_zone mei intel_soc_dts_iosf button lpc_ich soundcore shpchp > sch_fq_codel ip_tables x_tables btrfs xor raid6_pq jitterentropy_rng > sha256_ssse3 sha256_generic hmac drbg ansi_cprng algif_skcipher af_alg uas > usb_storage dm_crypt dm_mod sd_mod rtsx_pci_sdmmc atkbd libps2 > crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel > aes_x86_64 lrw gf128mul glue_helper > [ 748.244176] ablk_helper cryptd ahci libahci libata scsi_mod xhci_pci > rtsx_pci xhci_hcd i8042 serio sdhci_acpi sdhci led_class mmc_core pl2303 > mos7720 usbserial parport hid_generic usbhid hid usbcore usb_common > [ 748.246662] CPU: 0 PID: 2316 Comm: pacman Not tainted 4.5.1-1-ARCH #1 > [ 748.249123] Hardware name: Dell Inc. XPS 13 9343/0F5KF3, BIOS A07 > 11/11/2015 > [ 748.251576] task: 8800d9d98e40 ti: 8800cec1 task.ti: > 8800cec1 > [ 748.254064] RIP: 0010:[] [] > memmove_extent_buffer+0x10c/0x110 [btrfs] > [ 748.256600] RSP: 0018:8800cec13c18 EFLAGS: 00010246 > [ 748.259120] RAX: RBX: 88020c01ba40 RCX: > 0056 > [ 748.261631] RDX: RSI: 88021e40db38 RDI: > 88021e40db38 > [ 748.264166] RBP: 8800cec13c48 R08: R09: > 033b > [ 748.266716] R10: R11: 033b R12: > eece > [ 748.269267] R13: 00010405 R14: 000104c9 R15: > 88020c01ba40 > [ 748.271818] FS: 7f14d4271740() GS:88021e40() > knlGS: > [ 748.274392] CS: 0010 DS: ES: CR0: 80050033 > [ 748.276987] CR2: 01630008 CR3: cffc8000 CR4: > 003406f0 > [ 748.279603] DR0: DR1: DR2: > > [ 748.282220] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 748.284815] Stack: > [ 748.287422] e3438cd2 88020c01ba40 00c4 > 002a > [ 748.290082] 006b 03a0 8800cec13ce8 > a02b612c > [ 748.292754] a02b433d 8800da9ca820 0028 > 8800daa78bd0 > [ 748.295441] Call Trace: > [ 748.298104] [] btrfs_del_items+0x33c/0x4a0 [btrfs] > [ 748.300827] [] ? btrfs_search_slot+0x90d/0x990 [btrfs] > [ 748.303564] [] ? btrfs_get_token_8+0x6c/0x130 [btrfs] > [ 748.306311] [] btrfs_truncate_inode_items+0x649/0xd20 > [btrfs] > [ 748.309071] [] ? > btrfs_delayed_inode_release_metadata.isra.1+0x4e/0xf0 [btrfs] > [ 748.311860] [] btrfs_evict_inode+0x485/0x5d0 [btrfs] > [ 748.314627] [] evict+0xc5/0x190 > [ 748.317412] [] iput+0x1d9/0x260 > [ 748.320199] [] do_unlinkat+0x199/0x2d0 > [ 748.322988] [] SyS_unlink+0x16/0x20 > [ 748.325781] [] entry_SYSCALL_64_fastpath+0x12/0x6d > [ 748.328584] Code: 41 5e 41 5f 5d c3 48 8b 7f 18 48 89 f2 48 c7 c6 40 44 > 36 a0 e8 06 90 fa ff 0f 0
Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair
btrfs + dmcrypt + compress=lzo + autodefrag = corruption at first boot So discard is not the culprit. Will try to remove compress=lzo and autodefrag and see if it still happens. [ 748.224346] BTRFS error (device dm-0): memmove bogus src_offset 5431 move len 4294962894 len 16384 [ 748.226206] [ cut here ] [ 748.227831] kernel BUG at fs/btrfs/extent_io.c:5723! [ 748.229498] invalid opcode: [#1] PREEMPT SMP [ 748.231161] Modules linked in: ext4 mbcache jbd2 nls_iso8859_1 nls_cp437 vfat fat snd_hda_codec_hdmi dell_laptop dcdbas dell_wmi iTCO_wdt iTCO_vendor_support intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel arc4 kvm irqbypass psmouse serio_raw pcspkr elan_i2c snd_soc_ssm4567 snd_soc_rt286 snd_soc_rl6347a snd_soc_core i2c_hid iwlmvm snd_compress snd_pcm_dmaengine ac97_bus mac80211 uvcvideo videobuf2_vmalloc btusb videobuf2_memops cdc_ether btrtl usbnet iwlwifi btbcm videobuf2_v4l2 btintel intel_pch_thermal videobuf2_core i2c_i801 videodev r8152 rtsx_pci_ms cfg80211 bluetooth visor media mii memstick joydev evdev mousedev input_leds rfkill mac_hid crc16 i915 fan thermal wmi dw_dmac int3403_thermal video dw_dmac_core drm_kms_helper snd_soc_sst_acpi i2c_designware_platform snd_soc_sst_match [ 748.237203] snd_hda_intel 8250_dw i2c_designware_core gpio_lynxpoint spi_pxa2xx_platform drm int3402_thermal snd_hda_codec battery tpm_crb intel_hid snd_hda_core sparse_keymap fjes snd_hwdep int3400_thermal acpi_thermal_rel tpm_tis snd_pcm intel_gtt tpm acpi_als syscopyarea sysfillrect snd_timer sysimgblt fb_sys_fops mei_me i2c_algo_bit processor_thermal_device kfifo_buf processor snd industrialio acpi_pad ac int340x_thermal_zone mei intel_soc_dts_iosf button lpc_ich soundcore shpchp sch_fq_codel ip_tables x_tables btrfs xor raid6_pq jitterentropy_rng sha256_ssse3 sha256_generic hmac drbg ansi_cprng algif_skcipher af_alg uas usb_storage dm_crypt dm_mod sd_mod rtsx_pci_sdmmc atkbd libps2 crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper [ 748.244176] ablk_helper cryptd ahci libahci libata scsi_mod xhci_pci rtsx_pci xhci_hcd i8042 serio sdhci_acpi sdhci led_class mmc_core pl2303 mos7720 usbserial parport hid_generic usbhid hid usbcore usb_common [ 748.246662] CPU: 0 PID: 2316 Comm: pacman Not tainted 4.5.1-1-ARCH #1 [ 748.249123] Hardware name: Dell Inc. XPS 13 9343/0F5KF3, BIOS A07 11/11/2015 [ 748.251576] task: 8800d9d98e40 ti: 8800cec1 task.ti: 8800cec1 [ 748.254064] RIP: 0010:[] [] memmove_extent_buffer+0x10c/0x110 [btrfs] [ 748.256600] RSP: 0018:8800cec13c18 EFLAGS: 00010246 [ 748.259120] RAX: RBX: 88020c01ba40 RCX: 0056 [ 748.261631] RDX: RSI: 88021e40db38 RDI: 88021e40db38 [ 748.264166] RBP: 8800cec13c48 R08: R09: 033b [ 748.266716] R10: R11: 033b R12: eece [ 748.269267] R13: 00010405 R14: 000104c9 R15: 88020c01ba40 [ 748.271818] FS: 7f14d4271740() GS:88021e40() knlGS: [ 748.274392] CS: 0010 DS: ES: CR0: 80050033 [ 748.276987] CR2: 01630008 CR3: cffc8000 CR4: 003406f0 [ 748.279603] DR0: DR1: DR2: [ 748.282220] DR3: DR6: fffe0ff0 DR7: 0400 [ 748.284815] Stack: [ 748.287422] e3438cd2 88020c01ba40 00c4 002a [ 748.290082] 006b 03a0 8800cec13ce8 a02b612c [ 748.292754] a02b433d 8800da9ca820 0028 8800daa78bd0 [ 748.295441] Call Trace: [ 748.298104] [] btrfs_del_items+0x33c/0x4a0 [btrfs] [ 748.300827] [] ? btrfs_search_slot+0x90d/0x990 [btrfs] [ 748.303564] [] ? btrfs_get_token_8+0x6c/0x130 [btrfs] [ 748.306311] [] btrfs_truncate_inode_items+0x649/0xd20 [btrfs] [ 748.309071] [] ? btrfs_delayed_inode_release_metadata.isra.1+0x4e/0xf0 [btrfs] [ 748.311860] [] btrfs_evict_inode+0x485/0x5d0 [btrfs] [ 748.314627] [] evict+0xc5/0x190 [ 748.317412] [] iput+0x1d9/0x260 [ 748.320199] [] do_unlinkat+0x199/0x2d0 [ 748.322988] [] SyS_unlink+0x16/0x20 [ 748.325781] [] entry_SYSCALL_64_fastpath+0x12/0x6d [ 748.328584] Code: 41 5e 41 5f 5d c3 48 8b 7f 18 48 89 f2 48 c7 c6 40 44 36 a0 e8 06 90 fa ff 0f 0b 48 8b 7f 18 48 c7 c6 08 44 36 a0 e8 f4 8f fa ff <0f> 0b 66 90 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 48 89 fb [ 748.331558] RIP [] memmove_extent_buffer+0x10c/0x110 [btrfs] [ 748.334473] RSP [ 748.356077] ---[ end trace 9bfb28800ab52273 ]--- [ 748.359042] note: pacman[2316] exited with preempt_count 2 -- 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.
Re: random i/o error without error in dmesg
Am Saturday 07 May 2016 schrieb Marc Joliet >I'm thinking of filing >a bug report with dovecot; perhaps none of their devs test with btrfs? So I did this, and got a little bit of feedback. Quoting from the reply I got: "*.index.log files are always appended to using O_APPEND flag. Maybe this is relevant. Also when a new .log file is created it's opened without the O_APPEND flag and the O_APPEND is added later. This was causing a bug recently in unionfs, which ignored the flag change and caused log file corruption." The other bit of advise was to stress test dovecot using imaptest, but I'll have to do that when I have more time. Greetings -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup signature.asc Description: This is a digitally signed message part.
Re: commands like "du", "df", and "btrfs fs sync" hang
Am Thu, 5 May 2016 08:35:37 +0200 schrieb Kai Krakow : > Am Tue, 3 May 2016 08:48:14 +0200 > schrieb Kai Krakow : > > > Am Sun, 1 May 2016 20:39:31 -0400 > > schrieb Nicholas D Steeves : > > > > > On 1 May 2016 at 03:00, Kai Krakow > > > wrote: > [...] > > > > > > Out of curiosity, does this occur if you don't create or delete > > > snapshots, or if your backup script doesn't create or delete > > > snapshots? And when it occurs, are you able to go to another > > > terminal and run a command that you don't use often, that > > > definitely had to be read from disk, but that doesn't query any > > > filesystem properties (eg: whois)? > > > > I only create snapshots in the destination device, not on the > > source. I could try disabling the snapshotting and see if it > > changes things. > > > > It seems from my observation, that only programs querying disk free > > or disk usage status hang, especially all of the btrfs subcommands > > doing it hang, in addition to traditional programs like du and df. > > I think also "btrfs sub delete" and friends hang. So your guess may > > very well go into the right direction. Let me try. Coming back > > later... > > With the snapshot and sync related bits disabled in my script, I no > longer experience freezing df/du/... commands. Ah well, I still do - it just triggers much less often. But I can track it down to the automounter now: As soon as I stop the automounter of my backup device, du/df/etc no longer hang. Still I'm not sure if the problem is originating from btrfs or autofs itself. -- Regards, Kai Replies to list-only preferred. -- 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: How to rollback a snapshot of a subvolume with nested subvolumes?
Thanks, I hoped there was something like an hidden recursive flag to avoid the tedious task of snapshotting all the nested subvolumes or deleting the nested ones, but it seems there isn't. I usually don't want to keep things like /var/cache/pacman/pkg, but since I'm just doing some tests I didn't want to lose my packages cache. Regarding @/.snapshots it was an unfortunate choise made by snapper and I will definitely create it into the top level, like /srv which shouldn't belong to @. By the way snapper rollbacks are yet another reason to not keep subvolid along with subvol=@ into fstab, like in the one automatically generated by genfstab. Niccolò -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
btrfs-tools: missing device delete/remove cancel option on disk failure
He guys, i'm running in an rare error which isnt covered by an implemented usecase atm.i have a 4 hdd raid5 array. i like to replace the 4 disks with bigger ones to gain more usable space the NAS has only 4 drive bays so i need to use an usb bay. since the replace code was unreliable at least before 4.4 afaik, the plan was to add anew disk to the array, balance and remove one of the small disks this should be safe. BUT what if, if the new drive i'm adding is failing while doing the remove/delete operation? this is what i'm running into right now. a brand new disk which has an upcounting raw error rate. but there is no option to cancel an delete/remove operation. atm it isnt a problem for me. i hope to complete the operation successfully and replace the failingdrive afterwards. please consider to add an option to exit/cancel an delete/remove operation like in replace/scrub/... thx! sash --- Mail & Cloud Made in Germany mit 3 GB Speicher! https://email.freenet.de/mail/Uebersicht?epid=e990450 -- 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