[PATCH 3/3] btrfs-progs: clean up commands.h

This function is declared in utils.h so remove it from commands.h int test_issubvolume(const char *path); This function does not exists delete the declaration get_subvol_name(char *mnt, char *full_path); Signed-off-by: Anand Jain --- commands.h | 6 -- 1 file

[PATCH 1/3] btrfs-progs: fix make install failure

/usr/bin/install -c -m644 -d 64-btrfs-dm.rules /usr/lib/udev/rules.d /usr/bin/install: cannot create directory ‘64-btrfs-dm.rules’: File exists Makefile:400: recipe for target 'install' failed make: *** [install] Error 1 fixes: btrfs-progs: udev: add rules for dm devices Signed-off-by: Anand

[PATCH 2/3] btrfs-progs: add clean-all to the usage

Signed-off-by: Anand Jain --- Makefile.in | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile.in b/Makefile.in index 238dd59badaf..50b2ee5d8eba 100644 --- a/Makefile.in +++ b/Makefile.in @@ -6,6 +6,7 @@ # testrun the full testsuite # install

[PATCH 0/3] btrfs-progs: fixes on top of latest integration branch

Hi David, Your latest branch integration-20160517 is failing with make install, 1/3 will fix it. While here can you also apply 2/3 and 3/3 as below, however they aren't related though. Thanks Anand Jain (3): btrfs-progs: fix make install failure btrfs-progs: add clean-all to the

Re: Reducing impact of periodic btrfs balance

Qu Wenruo posted on Thu, 19 May 2016 09:33:19 +0800 as excerpted: > Graham Cobb wrote on 2016/05/18 14:29 +0100: >> Hi, >> >> I have a 6TB btrfs filesystem I created last year (about 60% used). It >> is my main data disk for my home server so it gets a lot of usage >> (particularly mail). I do

[PATCH] btrfs-progs: Return earlier for previous item

Follow kernel code to return earlier for btrfs_previous_item() function. Before this patch, btrfs_previous_item() doesn't use its min_objectid to exit, this makes caller to check key to exit, and if caller doesn't check, it will iterate all previous item. This patch will check min_objectid and

Re: Reducing impact of periodic btrfs balance

Graham Cobb wrote on 2016/05/18 14:29 +0100: Hi, I have a 6TB btrfs filesystem I created last year (about 60% used). It is my main data disk for my home server so it gets a lot of usage (particularly mail). I do frequent snapshots (using btrbk) so I have a lot of snapshots (about 1500 now,

Re: [PATCH] btrfs: switch to common message helpers in open_ctree, adjust messages

> You mean a shorter UUID? The first four bytes (8 hexa digits) seem > unique enough. That can be optinal I think. Yes. I said that. But I am also thinking FSID is user changeable (which is good), and so it should be easy to show that this method fails. Another way came to my mind: make

Re: incoming merge conflict to linux-next

Hi Chris, On Wed, 18 May 2016 17:10:43 -0400 Chris Mason wrote: > > Dave Sterba's tree in linux-next has a few btrfs patches that we're not > sending yet into Linus. We've got an update for Josef's enospc work > that'll get sent in next week. > > So he prepped a pull for me that

RE: Reducing impact of periodic btrfs balance

> -Original Message- > From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs- > ow...@vger.kernel.org] On Behalf Of Graham Cobb > Sent: Wednesday, 18 May 2016 11:30 PM > To: linux-btrfs@vger.kernel.org > Subject: Reducing impact of periodic btrfs balance > > Hi, > > I have a 6TB

Re: incoming merge conflict to linux-next

On Wed, May 18, 2016 at 05:10:43PM -0400, Chris Mason wrote: > Dave Sterba's tree in linux-next has a few btrfs patches that we're not > sending yet into Linus. We've got an update for Josef's enospc work > that'll get sent in next week. > > So he prepped a pull for me that merged up a number of

Re: [PATCH V2] Btrfs: introduce ticketed enospc infrastructure

On Tue, May 17, 2016 at 01:30:55PM -0400, Josef Bacik wrote: > V1->V2: > -fixed a check in space_info_add_old_bytes where we didn't take into account > bytes_may_used for the space used. > -don't count ticket->bytes when checking overcommit. I still see the warning in generic/333, same as with

Re: Hot data tracking / hybrid storage

Op Tue, 17 May 2016 20:33:35 +0200, schreef Kai Krakow: > Am Tue, 17 May 2016 07:32:11 -0400 schrieb "Austin S. Hemmelgarn" > : > >> On 2016-05-17 02:27, Ferry Toth wrote: >> > Op Mon, 16 May 2016 01:05:24 +0200, schreef Kai Krakow: >> > >> >> Am Sun, 15 May 2016 21:11:11

incoming merge conflict to linux-next

Hi Stephen, Dave Sterba's tree in linux-next has a few btrfs patches that we're not sending yet into Linus. We've got an update for Josef's enospc work that'll get sent in next week. So he prepped a pull for me that merged up a number of his branches but didn't include Josef's new code. It has

Re: [PATCH 6/7] Btrfs: fix eb memory leak due to readpage failure

On 05/13/2016 08:07 PM, Liu Bo wrote: eb->io_pages is set in read_extent_buffer_pages(). In case of readpage failure, for pages that have been added to bio, it calls bio_endio and later readpage_io_failed_hook() does the work. When this eb's page (couldn't be the 1st page) fails to add itself

Re: [PATCH] Btrfs: fix unexpected return value of fiemap

On Wed, May 18, 2016 at 11:41:05AM +0200, David Sterba wrote: > On Tue, May 17, 2016 at 05:21:48PM -0700, Liu Bo wrote: > > btrfs's fiemap is supposed to return 0 on success and > > return < 0 on error, however, ret becomes 1 after looking > > up the last file extent, and if the offset is beyond

Re: btrfs self tests fail on arm64, kernel 4.6

On 18 May 2016 at 17:58, Chandan Rajendra wrote: > On Wednesday 18 May 2016 16:46:49 Steve Capper wrote: >> Hello, >> I am running into issues running the btrfs self tests from 4.6 on an >> arm64 system with PAGE_SIZE=64K. >> Poking around in recalculate_thresholds(),

Re: btrfs self tests fail on arm64, kernel 4.6

On Wednesday 18 May 2016 16:46:49 Steve Capper wrote: > Hello, > I am running into issues running the btrfs self tests from 4.6 on an > arm64 system with PAGE_SIZE=64K. > Poking around in recalculate_thresholds(), I got the following values: > size = 1073741824 > ctl->unit = 4096 > bytes_per_bg =

btrfs self tests fail on arm64, kernel 4.6

Hello, I am running into issues running the btrfs self tests from 4.6 on an arm64 system with PAGE_SIZE=64K. Poking around in recalculate_thresholds(), I got the following values: size = 1073741824 ctl->unit = 4096 bytes_per_bg = 2147483648 max_bitmaps = 1 I am not sure where the problem is as

Re: [PATCH 5/7] Btrfs: replace BUG_ON with WARN in merge_bio

On Tue, May 17, 2016 at 10:30:47AM -0700, Liu Bo wrote: > > If merge_bio gets rid of the BUG_ON, the calles must explicitly handle > > 'ret < 0' unless it's provably not a problem. > > If merge_bio() returns < 0, then it must be __btrfs_map_block() returns < 0, > so even if we continue with

Reducing impact of periodic btrfs balance

Hi, I have a 6TB btrfs filesystem I created last year (about 60% used). It is my main data disk for my home server so it gets a lot of usage (particularly mail). I do frequent snapshots (using btrbk) so I have a lot of snapshots (about 1500 now, although it was about double that until I cut back

Re: [PATCH V2] Btrfs: introduce ticketed enospc infrastructure

On 2016-05-17 13:30, Josef Bacik wrote: Our enospc flushing sucks. It is born from a time where we were early enospc'ing constantly because multiple threads would race in for the same reservation and randomly starve other ones out. So I came up with this solution to block any other

Re: [PATCH] Btrfs: fix unexpected return value of fiemap

On Tue, May 17, 2016 at 05:21:48PM -0700, Liu Bo wrote: > btrfs's fiemap is supposed to return 0 on success and > return < 0 on error, however, ret becomes 1 after looking > up the last file extent, and if the offset is beyond EOF, > we can return 1. > > This may confuse applications using

Re: [PATCH 0/4] Add support to clear v1 free space cache for btrfs check

On Tue, May 17, 2016 at 08:12:20PM +0200, Ivan P wrote: > Thank you, however I can't seem to be able to compile that snapshot, I'm > getting > > === > /usr/bin/install -c -m644 -d 64-btrfs-dm.rules >

Re: BTRFS RAID 1 broken: Mounted drive(s) basically empty after repair attempt

Quanttek Jonas posted on Tue, 17 May 2016 10:00:41 -0400 as excerpted: > So, the question is: How can I recover from this? How do I get my data > back, after foolishly using "btrfsck --repair"? First, let me note that I'm a list regular and btrfs user, not a dev, and that as such, much of your