This parameter was introduced with the original implementation of the
function but has never really been used, so just remove it.
Signed-off-by: Nikolay Borisov
---
check/main.c | 2 +-
extent-tree.c | 10 +-
volumes.c | 7 ++-
volumes.h | 4 ++--
4 files changed, 10 inse
Commit 17793e3e6a49 ("Btrfs-progs: extend the extent cache for the
device extent") extended the cache extent APIs to support objectid to
distinguish between phyisical extents with same dimensions but on
different devices. However, it seems that this particular function is
not used to allocate a dev
This function is always called with objectid set to 0. So remove the
parameter and statically set the ->objectid to 0 when allocating a new
extent.
Signed-off-by: Nikolay Borisov
---
extent-cache.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/extent-cache.c b/extent
Here are a couple of cleanups I stumbled upon while looking at the freespace
validation code. The first one simplifies btrfs_rmap_block that has an unused
parameter. The next 2 patches cleanup the cache_extent apis since they provide
more than we are actually using (or have ever used).
Nikolay B
This function is used in only one place and devid argument is always
passed 0. So just remove it, similarly to how it was removed in the
userspace code.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent-tree.c | 2 +-
fs/btrfs/volumes.c | 7 ++-
fs/btrfs/volumes.h | 5 ++---
3 files
On 2018年05月04日 15:47, Nikolay Borisov wrote:
> Here are a couple of cleanups I stumbled upon while looking at the freespace
> validation code. The first one simplifies btrfs_rmap_block that has an unused
> parameter. The next 2 patches cleanup the cache_extent apis since they provide
> more tha
From: Colin Ian King
Trivial fix to spelling mistake of function name in btrfs_err message
Signed-off-by: Colin Ian King
---
fs/btrfs/send.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index c0074d2d7d6d..6e8184f239e0 100644
--- a/fs/bt
On 5/4/18 1:59 AM, Nikolay Borisov wrote:
>
>
> On 4.05.2018 01:27, Jeff Mahoney wrote:
>> On 5/3/18 2:23 AM, Nikolay Borisov wrote:
>>>
>>>
>>> On 3.05.2018 00:11, je...@suse.com wrote:
From: Jeff Mahoney
Hi Dave -
Here's the updated patchset for the rescan races. Th
On 4.05.2018 16:32, Jeff Mahoney wrote:
> On 5/4/18 1:59 AM, Nikolay Borisov wrote:
>>
>>
>> On 4.05.2018 01:27, Jeff Mahoney wrote:
>>> On 5/3/18 2:23 AM, Nikolay Borisov wrote:
On 3.05.2018 00:11, je...@suse.com wrote:
> From: Jeff Mahoney
>
> Hi Dave -
>
Hi,
please pull the following branch with 2 regression fixes and one fix for
stable. Thanks.
The following changes since commit c0872323746e11fc79344e3738b283a8cda86654:
btrfs: print-tree: debugging output enhancement (2018-04-20
Hi Qu,
The tool is still running and the log file is now ~300mb. I guess it
shouldn't normally take this long.. Is there anything else worth
trying?
Kind regards
Michael
On 2 May 2018 at 06:29, Michael Wade wrote:
> Thanks Qu,
>
> I actually aborted the run with the old btrfs tools once I saw i
Hello,
It's essential I confirm you are still at this email address before I divulge
exclusive details of the proposal I am offering.
Best Regards,
Sisira Deraniyagala
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
On 2018年05月05日 00:18, Michael Wade wrote:
> Hi Qu,
>
> The tool is still running and the log file is now ~300mb. I guess it
> shouldn't normally take this long.. Is there anything else worth
> trying?
I'm afraid not much.
Although there is a possibility to modify btrfs-find-root to do much
fas
13 matches
Mail list logo
