Re: runtime btrfsck

It's still running. Is this the normal behaviour? Is there any other way to fix the bad key ordering? Greets, Stefan Am 02.05.2017 um 08:29 schrieb Stefan Priebe - Profihost AG: > Hello list, > > i wanted to check an fs cause it has bad key ordering. > > But btrfscheck is now running since 7

[PATCH v2] btrfs: add framework to handle device flush error as a volume

This adds comments to the flush error handling part of the code, and hopes to maintain the same logic with a framework which can be used to handle the errors at the volume level. Signed-off-by: Anand Jain --- v2: fix -ENOMEM at two places add code readability changes in

Re: BTRFS converted from EXT4 becomes read-only after reboot

Please reply to all. You keep dropping Qu and the Btrfs list off your responses. On Fri, May 5, 2017 at 2:22 PM, Alexandru Guzu wrote: > I booted a Live CD with btrfs-progs 4.10.2 and ran a check on the > partition, the regular btrfs check did not find any errors, but the >

Re: help converting btrfs to new writeback error tracking?

On Fri, 2017-05-05 at 12:21 -0700, Liu Bo wrote: > Hi Jeff, > > On Thu, May 04, 2017 at 07:26:17AM -0400, Jeff Layton wrote: > > I've been working on set of patches to clean up how writeback errors are > > tracked and handled in the kernel: > > > >

Re: [PATCH ping] btrfs: warn about RAID5/6 being experimental at mount time

On Wed, Apr 26, 2017 at 04:14:16AM +0200, Adam Borowski wrote: > On Wed, Apr 19, 2017 at 11:07:45PM +0200, Adam Borowski wrote: > > Too many people come complaining about losing their data -- and indeed, > > there's no warning outside a wiki and the mailing list tribal knowledge. > > Message

Re: help converting btrfs to new writeback error tracking?

Hi Jeff, On Thu, May 04, 2017 at 07:26:17AM -0400, Jeff Layton wrote: > I've been working on set of patches to clean up how writeback errors are > tracked and handled in the kernel: > > http://marc.info/?l=linux-fsdevel=149304074111261=2 > > The basic idea is that rather than having a set of

Re: [PATCH 2/2] btrfs: Add quota_override knob into sysfs

On Fri, Apr 21, 2017 at 11:13:06PM +, Sargun Dhillon wrote: > This patch adds the read-write attribute quota_override into sysfs. > Any process which has cap_sys_resource can set this flag to on, and > once it is set to true, processes with cap_sys_resource can exceed > the quota. So we've

Re: [PATCH 1/2] btrfs: add quota override attribute

On Sun, Apr 23, 2017 at 09:48:34PM -0700, Sargun Dhillon wrote: > On Sun, Apr 23, 2017 at 8:42 PM, Qu Wenruo wrote: > > At 04/22/2017 07:12 AM, Sargun Dhillon wrote: > >> > >> This patch introduces the quota override flag to btrfs_fs_info, and > >> a change to quota limit

Re: [PATCH] btrfs: allow processes with cap_sys_resource to exceed quota

If you see my follow-on patch, it allows disabling the quota limit for folks with cap_sys_resource per filesystem. I don't want to have any process to be able to turn off quota limits, but just the process that is the logrotator (and has the proper capabilities). Unfortunately, most folks don't

Re: [PATCH] btrfs: allow processes with cap_sys_resource to exceed quota

On Fri, Apr 21, 2017 at 07:27:23AM -0500, Sargun Dhillon wrote: > What do you think about putting this behaviour behind a sysctl? Seems > better than to start introducing a new mechanism of marking tasks? Technically it's easy to add own btrfs-specific ioctl, temporarily turning off quota limits,

Re: btrfsck lowmem mode shows corruptions

Am Fri, 5 May 2017 08:55:10 +0800 schrieb Qu Wenruo : > At 05/05/2017 01:29 AM, Kai Krakow wrote: > > Hello! > > > > Since I saw a few kernel freezes lately (due to experimenting with > > ck-sources) including some filesystem-related backtraces, I booted > > my rescue

Re: [PATCH v3] btrfs: fiemap: Cache and merge fiemap extent before submit it to user

On Thu, Apr 13, 2017 at 08:36:24AM +0800, Qu Wenruo wrote: > > > At 04/12/2017 11:05 PM, David Sterba wrote: > > On Fri, Apr 07, 2017 at 10:43:15AM +0800, Qu Wenruo wrote: > >> [BUG] > >> Cycle mount btrfs can cause fiemap to return different result. > >> Like: > >> # mount /dev/vdb5

Re: [PATCH v3] btrfs: fiemap: Cache and merge fiemap extent before submit it to user

On Thu, Apr 20, 2017 at 12:52:55PM -0700, Liu Bo wrote: > On Thu, Apr 20, 2017 at 10:09:39AM +0800, Qu Wenruo wrote: > > > > > > At 04/20/2017 09:58 AM, Liu Bo wrote: > > > On Thu, Apr 20, 2017 at 09:52:00AM +0800, Qu Wenruo wrote: > > > > > > > > > [...] > > > > > > > > > > If I understand

Re: [PATCH v3] btrfs: fiemap: Cache and merge fiemap extent before submit it to user

On Thu, Apr 20, 2017 at 10:09:39AM +0800, Qu Wenruo wrote: > >>> If I understand it correctly, what it's missing currently is 'merge', a > >>> straightfoward idea is to make use of the 'merge' ability of > >>> btrfs_get_extent. > > >>> Since btrfs_get_extent_fiemap is a wrapper of

Re: [PATCH v2 8/9] btrfs: qgroup: Introduce extent changeset for qgroup reserve functions

On Tue, Apr 11, 2017 at 09:44:03AM +0800, Qu Wenruo wrote: > > I get that we cannot easily avoid using the extent_changeset, so we'll > > end up one way or another, the stack conservation has slight preference. > > Yes, I understand dynamic allocation can complicate the error handler. > > But

Re: [PATCH 5/6] Btrfs: change check-integrity to use bvec_iter

On Mon, Apr 17, 2017 at 06:16:26PM -0700, Liu Bo wrote: > Some check-integrity code depends on bio->bi_vcnt, this changes it to use > bio segments because some bios passing here may not have a reliable > bi_vcnt. > > Signed-off-by: Liu Bo > --- > fs/btrfs/check-integrity.c

Wrong received UUIDs after backup restore and onward

Hi, I ran into a situation where my incremental backups using send|receive are failing after a full file system failure followed by restore from an external backup. The reason for the failures seem to be that the Received UUID of snapshots and backups are not properly updated. In short,

Re: [PATCH] Btrfs: tolerate errors if we have retried successfully

On Thu, Apr 13, 2017 at 06:11:56PM -0700, Liu Bo wrote: > With raid1 profile, dio read isn't tolerating IO errors if read length is > less than the stripe length (64K). Can you please write more details why this is true? Some pointers to code etc, I'm lost. Eg. where the errors is tolerated.

Re: [PATCH] btrfs: cleanup qgroup trace event

On Fri, May 05, 2017 at 10:09:36AM +0800, Anand Jain wrote: > Commit 81fb6f77a026 (btrfs: qgroup: Add new trace point for > qgroup data reserve) added the following events which aren't used. > btrfs__qgroup_data_map > btrfs_qgroup_init_data_rsv_map > btrfs_qgroup_free_data_rsv_map > So

[PATCH 3/3] Btrfs: don't pass the inode through clean_io_failure

Instead pass around the failure tree and the io tree. Signed-off-by: Josef Bacik --- fs/btrfs/extent_io.c | 51 --- fs/btrfs/extent_io.h | 10 +++--- fs/btrfs/inode.c | 37 ++--- 3 files

[PATCH 2/3] btrfs: remove inode argument from repair_io_failure

Once we remove the btree_inode we won't have an inode to pass anymore, just pass the fs_info directly and the inum since we use that to print out the repair message. Signed-off-by: Josef Bacik --- fs/btrfs/extent_io.c | 16 +++- fs/btrfs/extent_io.h | 6 +++---

[PATCH 1/3] Btrfs: replace tree->mapping with tree->private_data

For extent_io tree's we have carried the address_mapping of the inode around in the io tree in order to pull the inode back out for calling into various tree ops hooks. This works fine when everything that has an extent_io_tree has an inode. But we are going to remove the btree_inode, so we need

[PATCH 0/3] Kill btree inode prep patches

These three patches are just prep patches for the kill btree inode patch, they just move some stuff around so we don't depend on struct inode in places where we won't have one. Once the other supporting generic code goes in I'll submit the kill btree inode patch as well. Thanks, Josef -- To

Re: 4.11 relocate crash, null pointer + rolling back a filesystem by X hours?

Thanks again for your answer. Obviously even if my filesystem is toast, it's useful to learn from what happened. On Fri, May 05, 2017 at 01:03:02PM +0800, Qu Wenruo wrote: > > > So unfortunately, your fs/subvolume trees are also corrupted. > > > And almost no chance to do a graceful recovery. > >

Re: BTRFS converted from EXT4 becomes read-only after reboot

On Fri, May 5, 2017 at 8:56 AM, Alexandru Guzu wrote: > btrfs-progs is 4.4 That's before the rewrite of convert. > I upgraded the kernel to 4.8.0-51 and the issue persists. > However, I noticed that the issue is triggered when I start Firefox. I > think Firefox starts

Re: [PATCH] btrfs: add framework to handle device flush error as a volume

On Tue, Apr 25, 2017 at 04:58:31PM +0800, Anand Jain wrote: > This adds comments to the flush error handling part of > the code, and hopes to maintain the same logic with a > framework which can be used to handle the errors at the > volume level. > > Signed-off-by: Anand Jain

Re: [PATCH 0/6 RFC] utilize bio_clone_fast to clean up

On Mon, Apr 17, 2017 at 06:16:21PM -0700, Liu Bo wrote: > This attempts to use bio_clone_fast() in the places where we clone bio, > such as when bio got cloned for multiple disks and when bio got split > during dio submit. > > One benefit is to simplify dio submit to avoid calling bio_add_page