[PATCH] Btrfs: fix an integer overflow check

This isn't super serious because you need CAP_ADMIN to run this code. I added this integer overflow check last year but apparently I am rubbish at writing integer overflow checks... There are two issues. First, access_ok() works on unsigned long type and not u64 so on 32 bit systems the

Thoughts on 'btrfs device stats' and security.

I'm currently working on a plugin for colllectd [1] to track per-device per-filesystem error rates for BTRFS volumes. Overall, this is actually going quite well (I've got most of the secondary logic like matching filesystems to watch and parsing the data done already), but I've come across a

Re: BTRFS Metadata Corruption Prevents Scrub and btrfs check

Peter, > Bad news. That means that probably the disk is damaged and > further issues may happen. This system has a long history, I have had a dual drive failure in the past, I managed to recover from that with ddrescue. I've subsequently copied the contents of the drives to new disks and

Re: BTRFS Metadata Corruption Prevents Scrub and btrfs check

On 2017-03-17 15:25, John Marrett wrote: Peter, Bad news. That means that probably the disk is damaged and further issues may happen. This system has a long history, I have had a dual drive failure in the past, I managed to recover from that with ddrescue. I've subsequently copied the

Re: Home storage with btrfs

I have had some troubles recently using btrfs with kernels >=4.8 when using the cfq scheduler. Please see my post: http://www.spinics.net/lists/linux-btrfs/msg63599.html I have no problem with kernels < 4.8 or when using the deadline scheduler (or none). It is possible that the problem I see

Re: [PULL] Btrfs updates for 4.11-rc2

On 03/09/2017 08:55 AM, David Sterba wrote: Hi, there's a regression fix for the assertion failure reported by Dave Jones, the rest of patches are minor updates. Please pull, thanks. The following changes since commit e9f467d028cd7d8bee2a4d6c4fb806caf8cd580b: Merge branch

Re: [PATCH 3/5] btrfs: raid56: Use correct stolen pages to calculate P/Q

On Fri, Mar 17, 2017 at 02:31:08PM +0800, Qu Wenruo wrote: > > > At 03/16/2017 01:36 PM, Liu Bo wrote: > > On Fri, Feb 03, 2017 at 04:20:21PM +0800, Qu Wenruo wrote: > > > In the following situation, scrub will calculate wrong parity to > > > overwrite correct one: > > > > > > RAID5 full

Re: BTRFS Metadata Corruption Prevents Scrub and btrfs check

> How can I attempt to rebuild the metadata, with a treescan or > otherwise? I don't know unfortunately for backrefs. >> In general metadata in Btrfs is fairly intricate and metadata >> block loss is pretty fatal, that's why metadata should most >> times be redundant as in 'dup' or 'raid1' or

Re: [PATCH 5/5] btrfs: replace: Use ref counts to avoid destroying target device when canceled

On Fri, Feb 03, 2017 at 04:20:23PM +0800, Qu Wenruo wrote: > When dev-replace and scrub are run at the same time, dev-replace can be > canceled by scrub. It's quite common for btrfs/069. > > The backtrace would be like: > general protection fault: [#1] SMP > Workqueue: btrfs-endio-raid56

Re: [PATCH 4/5] btrfs: raid56: Don't keep rbio for later steal

On Fri, Mar 17, 2017 at 01:28:45PM +0800, Qu Wenruo wrote: > > > At 03/17/2017 12:44 PM, Liu Bo wrote: > > On Fri, Feb 03, 2017 at 04:20:22PM +0800, Qu Wenruo wrote: > > > Before this patch, btrfs raid56 will keep raid56 rbio even all its IO is > > > done. > > > This may save some time

Re: Thoughts on 'btrfs device stats' and security.

On 2017-03-17 15:01, Eric Sandeen wrote: On 3/17/17 11:25 AM, Austin S. Hemmelgarn wrote: I'm currently working on a plugin for colllectd [1] to track per-device per-filesystem error rates for BTRFS volumes. Overall, this is actually going quite well (I've got most of the secondary logic

Re: Thoughts on 'btrfs device stats' and security.

On 3/17/17 11:25 AM, Austin S. Hemmelgarn wrote: > I'm currently working on a plugin for colllectd [1] to track per-device > per-filesystem error rates for BTRFS volumes. Overall, this is actually > going quite well (I've got most of the secondary logic like matching > filesystems to watch and

Re: help : "bad tree block start" -> btrfs forced readonly

Hi, Le 17/03/2017 à 09:43, Hans van Kranenburg a écrit : > btrfs-debug-tree -b 3415463870464 Here is what it gives me back : btrfs-debug-tree -b 3415463870464 /dev/sdb btrfs-progs v4.6.1 checksum verify failed on 3415463870464 found A85405B7 wanted 01010101 checksum verify failed on

Re: help : "bad tree block start" -> btrfs forced readonly

On Fri, 17 Mar 2017 10:27:11 +0100 Lionel Bouton wrote: > Hi, > > Le 17/03/2017 à 09:43, Hans van Kranenburg a écrit : > > btrfs-debug-tree -b 3415463870464 > > Here is what it gives me back : > > btrfs-debug-tree -b 3415463870464 /dev/sdb > btrfs-progs v4.6.1

Re: [PATCH 3/5] btrfs: raid56: Use correct stolen pages to calculate P/Q

At 03/16/2017 01:36 PM, Liu Bo wrote: On Fri, Feb 03, 2017 at 04:20:21PM +0800, Qu Wenruo wrote: In the following situation, scrub will calculate wrong parity to overwrite correct one: RAID5 full stripe: Before | Dev 1 | Dev 2 | Dev 3 | | Data stripe 1 | Data

Re: help : "bad tree block start" -> btrfs forced readonly

On 03/17/2017 09:11 AM, Lionel Bouton wrote: > Le 17/03/2017 à 05:32, Lionel Bouton a écrit : >> Hi, >> >> [...] >> I'll catch some sleep right now (it's 5:28 AM here) but I'll be able to >> work on this in 3 or 4 hours. > > I woke up to this : > > Mar 17 06:56:30 fileserver kernel:

Re: help : "bad tree block start" -> btrfs forced readonly

On 03/17/2017 10:27 AM, Lionel Bouton wrote: > Hi, > > Le 17/03/2017 à 09:43, Hans van Kranenburg a écrit : >> btrfs-debug-tree -b 3415463870464 > > Here is what it gives me back : > > btrfs-debug-tree -b 3415463870464 /dev/sdb > btrfs-progs v4.6.1 > checksum verify failed on 3415463870464

Re: help : "bad tree block start" -> btrfs forced readonly

Le 17/03/2017 à 05:32, Lionel Bouton a écrit : > Hi, > > [...] > I'll catch some sleep right now (it's 5:28 AM here) but I'll be able to > work on this in 3 or 4 hours. I woke up to this : Mar 17 06:56:30 fileserver kernel: btree_readpage_end_io_hook: 104476 callbacks suppressed Mar 17 06:56:30

BTRFS Metadata Corruption Prevents Scrub and btrfs check

I have a filesystem with uncorrectable errors in metadata. In the past when I've experienced corruption due to drive failures it affected the data and not metadata. I was able to delete the files and restored their content from backup. Unfortunately I can't do this this time as I have no way to

Re: [PATCH 5/8] nowait aio: return on congested block device

On 03/16/2017 09:33 AM, Jens Axboe wrote: > On 03/15/2017 03:51 PM, Goldwyn Rodrigues wrote: >> diff --git a/block/blk-core.c b/block/blk-core.c >> index 0eeb99e..2e5cba2 100644 >> --- a/block/blk-core.c >> +++ b/block/blk-core.c >> @@ -2014,7 +2019,7 @@ blk_qc_t generic_make_request(struct bio

Re: [PATCH 5/8] nowait aio: return on congested block device

On 03/16/2017 04:31 PM, Dave Chinner wrote: > On Wed, Mar 15, 2017 at 04:51:04PM -0500, Goldwyn Rodrigues wrote: >> From: Goldwyn Rodrigues >> >> A new flag BIO_NOWAIT is introduced to identify bio's >> orignating from iocb with IOCB_NOWAIT. This flag indicates >> to return

Re: help : "bad tree block start" -> btrfs forced readonly

Le 17/03/2017 à 10:51, Roman Mamedov a écrit : > On Fri, 17 Mar 2017 10:27:11 +0100 > Lionel Bouton wrote: > >> Hi, >> >> Le 17/03/2017 à 09:43, Hans van Kranenburg a écrit : >>> btrfs-debug-tree -b 3415463870464 >> Here is what it gives me back : >> >>

Re: BTRFS Metadata Corruption Prevents Scrub and btrfs check

> Read error at byte 0, while reading 3975 bytes: Input/output error Bad news. That means that probably the disk is damaged and further issues may happen. > corrected errors: 0, uncorrectable errors: 2, unverified errors: 0 Even worse news. > Incorrect local backref count on

Re: help : "bad tree block start" -> btrfs forced readonly

Hi, some news from the coal mine... Le 17/03/2017 à 11:03, Lionel Bouton a écrit : > [...] > I'm considering trying to use a 4 week old snapshot of the device to > find out if it was corrupted or not instead. It will still be a pain if > it works but rsync for less than a month of data is at

Btrfs progs release 4.10.1

Hi, btrfs-progs version 4.10.1 have been released. The build breakages are fixed now and convert rollback now works again. Changes: * receive: handle subvolume in path clone * convert: rollback fixed (rewrite was needed to address previous design issues) * build: fix build of 3rd party