RE: [GIT PULL] Fix for btrfs/070 checksum error

Hi, Chris > -Original Message- > From: linux-btrfs-ow...@vger.kernel.org > [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Qu Wenruo > Sent: Tuesday, July 28, 2015 3:11 PM > To: Chris Mason; btrfs > Subject: Re: [GIT PULL] Fix for btrfs/070 checksum error > > Chris Mason wrote on

Re: [GIT PULL] Fix for btrfs/070 checksum error

On Wed, Jul 29, 2015 at 04:21:33PM +0800, Zhao Lei wrote: > Hi, Chris > > > -Original Message- > > From: linux-btrfs-ow...@vger.kernel.org > > [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Qu Wenruo > > Sent: Tuesday, July 28, 2015 3:11 PM > > To: Chris Mason; btrfs > > Subject:

[PATCH] Btrfs: teach backref walking about backrefs with underflowed offset values

From: Filipe Manana When cloning/deduplicating file extents (through the clone and extent_same ioctls) we can get data back references with offset values that are a result of an unsigned integer arithmetic underflow, that is, values that are much larger then they could be otherwise. This is not

Re: Strange data backref offset?

On Fri, Jul 17, 2015 at 3:38 AM, Qu Wenruo wrote: > Hi all, > > While I'm developing a new btrfs inband dedup mechanism, I found btrfsck and > kernel doing strange behavior for clone. > > [Reproducer] > # mount /dev/sdc -t btrfs /mnt/test > # dd if=/dev/zero of=/mnt/test/file1 bs=4K count=4 > # sy

[PATCH] fstests: test for btrfs incremental send after file extent cloning

From: Filipe Manana Test that an incremental send works after a file gets one of its extents cloned/deduplicated into lower file offsets. This is a regression test for the problem fixed by the linux kernel patch titled: "Btrfs: teach backref walking about backrefs with underflowed offset v

fs got readonly after "btrfs_run_delayed_refs:2783: errno=-5 IO failure"

Hi At my home machine I use btrfs from the latest Linux kernel (Linux Arch). A few days ago I started rebalance but unfortunately the machine got rebooted. It looks like rebalance operation is not interrupt-tolerant and now my filesystem got corrupted. I see a lot of checksum errors, but as I us

[PATCH 1/1] btrfs-progs: compilation errors when using musl libc

- limits.h must be included to pick up PATH_MAX. - remove double declaration of BTRFS_DISABLE_BACKTRACE kerncompat.h assumed that if __GLIBC__ was not defined, it could safely define BTRFS_DISABLE_BACKTRACE, however this can be defined by the configure script. Added a check to ensure it is not def

Re: fs got readonly after "btrfs_run_delayed_refs:2783: errno=-5 IO failure"

Anatol Pomozov posted on Wed, 29 Jul 2015 09:26:00 -0700 as excerpted: > At my home machine I use btrfs from the latest Linux kernel (Linux > Arch). Similar here, but on gentoo. And to be clear, just a list regular and btrfs user as yourself, not a dev. As such, this reply isn't intended to d

Re: fs got readonly after "btrfs_run_delayed_refs:2783: errno=-5 IO failure"

Hi, I see a lot of checksum errors, but as I use RAID most of these error got fixed, I started scrub operation to find/fix all the problems but the scrub operation got cancelled at the very beginning. I see following error in kernel logs, it says "(device sdb): run_one_delayed_ref returned -5"

Re: [PATCH][RESEND] btrfs: fix search key advancing condition

Hello, list. Could any one take a look at on this? I believe this is a issue slowing down ioctl(BTRFS_IOC_TREE_SEARCH) if the target key is missing. On Tue, Jun 30, 2015 at 11:25 AM, Naohiro Aota wrote: > The search key advancing condition used in copy_to_sk() is loose. It can > advance the key