Re: Adventures in btrfs raid5 disk recovery

On Mon, Jun 20, 2016 at 09:55:59PM -0400, Zygo Blaxell wrote: > In this current case, I'm getting things like this: > > [12008.243867] BTRFS info (device vdc): csum failed ino 4420604 extent > 26805825306624 csum 4105596028 wanted 787343232 mirror 0 [...] > The other other weird thing here is

[PATCH] btrfs: add missing bytes_readonly attribute file in sysfs

Signed-off-by: Wang Xiaoguang --- fs/btrfs/sysfs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c index 4da84ca..7b0fcca 100644 --- a/fs/btrfs/sysfs.c +++ b/fs/btrfs/sysfs.c @@ -328,6 +328,7 @@ SPACE_INFO_ATTR(bytes_used);

Re: Adventures in btrfs raid5 disk recovery

On Mon, Jun 20, 2016 at 03:27:03PM -0600, Chris Murphy wrote: > On Mon, Jun 20, 2016 at 2:40 PM, Zygo Blaxell > wrote: > > On Mon, Jun 20, 2016 at 01:30:11PM -0600, Chris Murphy wrote: > > >> For me the critical question is what does "some corrupted sectors" mean?

Re: [RFC PATCH] btrfs: fix free space calculation in dump_space_info()

hello, On 06/21/2016 02:09 AM, Omar Sandoval wrote: On Mon, Jun 20, 2016 at 06:47:05PM +0800, Wang Xiaoguang wrote: Signed-off-by: Wang Xiaoguang --- fs/btrfs/extent-tree.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: Confusing output from fi us/df

On 2016/06/21 8:30, Marc Grondin wrote: > Hi everyone, > > > I have a btrfs filesystem ontop of a 4x1tb mdraid raid5 array and I've > been getting confusing output on metadata usage. Seems that even tho > both data and metadata are in single profile metadata is reporting > double the space(as if

Re: [PATCH v11 00/13] Btrfs dedupe framework

At 06/21/2016 12:03 AM, David Sterba wrote: Hi, I'm looking how well does this patchset merges with the rest, so far there are excpected conflicts with Chandan's subpage-blocksize patchset. For the easy parts, we can add stub patches to extend functions like cow_file_range with parameters

Re: Confusing output from fi us/df

Hi, On 06/21/2016 01:30 AM, Marc Grondin wrote: I have a btrfs filesystem ontop of a 4x1tb mdraid raid5 array and I've been getting confusing output on metadata usage. Seems that even tho both data and metadata are in single profile metadata is reporting double the space(as if it was in dupe

Confusing output from fi us/df

Hi everyone, I have a btrfs filesystem ontop of a 4x1tb mdraid raid5 array and I've been getting confusing output on metadata usage. Seems that even tho both data and metadata are in single profile metadata is reporting double the space(as if it was in dupe profile) root@thebeach /h/marcg>

Re: Adventures in btrfs raid5 disk recovery

On Mon, Jun 20, 2016 at 2:40 PM, Zygo Blaxell wrote: > On Mon, Jun 20, 2016 at 01:30:11PM -0600, Chris Murphy wrote: >> For me the critical question is what does "some corrupted sectors" mean? > > On other raid5 arrays, I would observe a small amount of corruption

Re: Adventures in btrfs raid5 disk recovery

On Mon, Jun 20, 2016 at 01:30:11PM -0600, Chris Murphy wrote: > On Mon, Jun 20, 2016 at 1:11 PM, Zygo Blaxell > wrote: > > On Mon, Jun 20, 2016 at 11:13:51PM +0500, Roman Mamedov wrote: > >> On Sun, 19 Jun 2016 23:44:27 -0400 > Seems difficult at best due to this:

Re: Adventures in btrfs raid5 disk recovery

On Mon, Jun 20, 2016 at 1:11 PM, Zygo Blaxell wrote: > On Mon, Jun 20, 2016 at 11:13:51PM +0500, Roman Mamedov wrote: >> On Sun, 19 Jun 2016 23:44:27 -0400 >> Zygo Blaxell wrote: >> From a practical standpoint, [aside from not using

Re: Adventures in btrfs raid5 disk recovery

On Mon, Jun 20, 2016 at 11:13:51PM +0500, Roman Mamedov wrote: > On Sun, 19 Jun 2016 23:44:27 -0400 > Zygo Blaxell wrote: > From a practical standpoint, [aside from not using Btrfs RAID5], you'd be > better off shutting down the system, booting a rescue OS, copying

Re: [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

> This version now looks ok to me. > > I do have a comment (or maybe just a RFD) for future work. > > It does strike me that once we actually change over the inode times to > use timespec64, the calling conventions are going to be fairly > horrendous on most 32-bit architectures. > > Gcc handles

Re: Scrub aborts on newer kernels

On Mon, Jun 20, 2016 at 3:22 AM, Tyson Whitehead wrote: > On 17/06/16 06:18 PM, Chris Murphy wrote: >> >> On Fri, Jun 17, 2016 at 8:45 AM, Tyson Whitehead >> wrote: >>> >>> On May 27, 2016 12:12:54 PM Chris Murphy wrote: On Thu, May 26, 2016

Re: Adventures in btrfs raid5 disk recovery

On Sun, 19 Jun 2016 23:44:27 -0400 Zygo Blaxell wrote: > It's not going well so far. Pay attention, there are at least four > separate problems in here and we're not even half done yet. > > I'm currently using kernel 4.6.2 with btrfs fixes forward-ported from >

Re: Scrub aborts on newer kernels

On Mon, Jun 20, 2016 at 3:22 AM, Tyson Whitehead wrote: > On 17/06/16 06:18 PM, Chris Murphy wrote: >> >> On Fri, Jun 17, 2016 at 8:45 AM, Tyson Whitehead >> wrote: >>> >>> On May 27, 2016 12:12:54 PM Chris Murphy wrote: On Thu, May 26, 2016

Re: [RFC PATCH] btrfs: fix free space calculation in dump_space_info()

On Mon, Jun 20, 2016 at 06:47:05PM +0800, Wang Xiaoguang wrote: > Signed-off-by: Wang Xiaoguang > --- > fs/btrfs/extent-tree.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c > index

Re: [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

On Sun, Jun 19, 2016 at 5:26 PM, Deepa Dinamani wrote: > The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC > macros. This version now looks ok to me. I do have a comment (or maybe just a RFD) for future work. It does strike me that once we

Is "btrfs balance start" truly asynchronous?

Dear btfs community, I have added a drive to existing raid1 btrfs volume and decided to perform balancing so that data distributes "fairly" among drives. I have started "btrfs balance start", but it stalled for about 5-10 minutes intensively doing the work. After that time it has printed

Re: [PATCH v11 00/13] Btrfs dedupe framework

Hi, I'm looking how well does this patchset merges with the rest, so far there are excpected conflicts with Chandan's subpage-blocksize patchset. For the easy parts, we can add stub patches to extend functions like cow_file_range with parameters that are added by the other patch. Honestly I

Re: [PATCH] Btrfs: fix ->iterate_shared() by upgrading i_rwsem for delayed nodes

On Fri, Jun 17, 2016 at 10:55:54AM -0700, Omar Sandoval wrote: > On Wed, May 25, 2016 at 04:22:26PM -0400, Chris Mason wrote: > > On Wed, May 25, 2016 at 10:11:29PM +0200, David Sterba wrote: > > > On Fri, May 20, 2016 at 01:50:33PM -0700, Omar Sandoval wrote: > > > > Commit fe742fd4f90f ("Revert

Re: dd on wrong device, 1.9 GiB from the beginning has been overwritten, how to restore partition?

Hey, I want you to know that it was impossible to recover the filesystem and that I have recreated the partition. Lost ~1.5 TiB unredundant data but it's just an annoyance, no catastrophe – I can recreate my collection and it wasn't any critical data. For others with related problems: My

Re: [PATCH V19 05/19] Btrfs: subpage-blocksize: Read tree blocks whose size is < PAGE_SIZE

On Monday, June 20, 2016 01:54:05 PM David Sterba wrote: > On Tue, Jun 14, 2016 at 12:41:02PM +0530, Chandan Rajendra wrote: > > In the case of subpage-blocksize, this patch makes it possible to read > > only a single metadata block from the disk instead of all the metadata > > blocks that map

Re: btrfs: page allocation failure: order:1, mode:0x2204020

On Sat, Jun 18, 2016 at 08:47:55PM +0200, Hans van Kranenburg wrote: > Last night, one of my btrfs filesystems went read-only after a memory > allocation failure (logging attached). According to the logs, the allocation itself happens out of btrfs so we can't do much here. More specifically,

Re: [PATCH V19 05/19] Btrfs: subpage-blocksize: Read tree blocks whose size is < PAGE_SIZE

On Tue, Jun 14, 2016 at 12:41:02PM +0530, Chandan Rajendra wrote: > In the case of subpage-blocksize, this patch makes it possible to read > only a single metadata block from the disk instead of all the metadata > blocks that map into a page. This patch has a conflict with a next pending patch

Re: [PATCH V19 11/19] Btrfs: subpage-blocksize: Prevent writes to an extent buffer when PG_writeback flag is set

On Tue, Jun 14, 2016 at 12:41:08PM +0530, Chandan Rajendra wrote: > In non-subpage-blocksize scenario, BTRFS_HEADER_FLAG_WRITTEN flag > prevents Btrfs code from writing into an extent buffer whose pages are > under writeback. This facility isn't sufficient for achieving the same > in

On shrinkable caches

Hello, I have a question regarding the SLAB_RECLAIM_ACCOUNT flag with which BTRFS caches are created. Currently there isn't a single usage of register_shrinker under fs/btrfs. Apart from the inode cache which is being shrunk from the generic super_cache_scan I don't think the memory used for

Re: [PATCH v2 08/24] fs: btrfs: Use ktime_get_real_ts for root ctime

On Sun, Jun 19, 2016 at 05:27:07PM -0700, Deepa Dinamani wrote: > btrfs_root_item maintains the ctime for root updates. > This is not part of vfs_inode. > > Since current_time() uses struct inode* as an argument > as Linus suggested, this cannot be used to update root > times unless, we modify

Re: Scrub aborts on newer kernels

On 17/06/16 06:18 PM, Chris Murphy wrote: On Fri, Jun 17, 2016 at 8:45 AM, Tyson Whitehead wrote: On May 27, 2016 12:12:54 PM Chris Murphy wrote: On Thu, May 26, 2016 at 11:55 AM, Tyson Whitehead wrote: Under the last several kernels versions (4.6

Re: [PATCH 2/2] btrfs: wait for bdev put

On 06/19/2016 12:34 AM, Holger Hoffstätte wrote: On Tue, 14 Jun 2016 18:55:26 +0800, Anand Jain wrote: Further to the previous commit bc178622d40d87e75abc131007342429c9b03351 btrfs: use rcu_barrier() to wait for bdev puts at unmount Since free_device() spinoff __free_device() the