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 changed, 6 deletions(-)
diff -
/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 Jain
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 install to default location
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 usa
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 fr
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 ty
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, al
> 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 it
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 merged up a num
> -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 btr
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
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 v1
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 + (UTC)
>> >> schr
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
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 t
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 E
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(), I got the following values:
>
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 = 2
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 I'm
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 submit
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
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 reservations
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 ioctl(
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
> /home/myuser/aur/btrfs-progs-git/pkg/btrfs-progs-git/usr/lib/udev/rules.d
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 p
25 matches
Mail list logo