linux-kernel - Re: [PATCH 00/30] DRBD updates

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <575ECD32.2080700@fb.com>
Date:	Mon, 13 Jun 2016 09:11:46 -0600
From:	Jens Axboe <axboe@...com>
To:	Philipp Reisner <philipp.reisner@...bit.com>,
	<linux-kernel@...r.kernel.org>
CC:	<drbd-dev@...ts.linbit.com>
Subject: Re: [PATCH 00/30] DRBD updates

On 06/13/2016 08:08 AM, Philipp Reisner wrote:
> Hi Jens,
>
> I have sent this already on April 25, I guess it was too late in the cycle
> at that time. Apart from the usual maintenance and bug fixes this time comes
> support for WRITE_SAME and lots of improvements for DISCARD.
>
> At that time we had a discussion about (1) the all_zero() heuristic introduced
> with [PATCH 04/30] drbd: Implement handling of thinly provisioned storage...
> not being efficient, and about the (2) rs-discard-granularity configuration
> parameter.
>
> Regarding (1): I intend to work on block-devices being able to export their
> allocation map by either FIEMAP or SEEK_HOLE/SEEK_DATA or both for the next
> cycle. The I will change DRBD to use that as well.
>
> Regarding (2): We need to announce the discard granularity when we create the
> device/minor. At might it might be that there is no connection to the peer
> node. So we are left with information about the discard granularity of the
> local backing device only. Therefore we decided to delegate it to the
> user/admin to provide the discard granularity for the resync process.
>
>
> Please add it to your for-4.8/drivers branch.

If you want me to add it to that branch (which is where it should go), 
then why aren't the patches against that branch? I get rejects on 
several of the patches, mainly because they are not done on top of this 
particular branch.

We can do two things here. I can skip patches, I don't like doing that. 
Or you can respin against the proper branch, as it should have been from 
the beginning. What do you want to do?

-- 
Jens Axboe