Re: [PATCH] btrfs-progs: udev: add rules for dm devices

[Andrei Borzenkov]

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

[Martin]

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

[Chris Murphy]

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

[Adam Borowski]

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

[M G Berberich]

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

[Niccolò Belli]

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

[Clemens Eisserer]

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

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

[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 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  

Re: random i/o error without error in dmesg

[Marc Joliet]

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

[Kai Krakow]

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?

[Niccolò Belli]

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

[g6094199]

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