On Wed, May 03 2017, Mikulas Patocka wrote:
> On Mon, 24 Apr 2017, NeilBrown wrote:
>>
>> I had a look at how the allocation 'dm_region' objects are used,
>> and it would take a bit of work to make it really safe.
>> My guess is __rh_find() should be allowed to fail, and the various
>> callers
On Wed, May 03 2017 at 1:51pm -0400,
Linus Torvalds wrote:
> On Tue, May 2, 2017 at 11:58 AM, Mike Snitzer wrote:
> >
> > - Add a new DM integrity target that emulates a block device that has
> > additional per-sector tags that can be used
On Mon, 24 Apr 2017, NeilBrown wrote:
> On Fri, Apr 21 2017, Mikulas Patocka wrote:
>
> > On Mon, 10 Apr 2017, NeilBrown wrote:
> >
> >> mempool_alloc() should only be called with GFP_ATOMIC when
> >> it is not safe to wait. Passing __GFP_NOFAIL to kmalloc()
> >> says that it is safe to wait
On Tue, May 2, 2017 at 11:58 AM, Mike Snitzer wrote:
>
> - Add a new DM integrity target that emulates a block device that has
> additional per-sector tags that can be used for storing integrity
> information.
So this one comes with a nice documentation file and
On Tue, May 02 2017 at 11:33pm -0400,
Nicholas A. Bellinger wrote:
> On Tue, 2017-05-02 at 09:23 +0200, h...@lst.de wrote:
> > On Tue, May 02, 2017 at 12:16:13AM -0700, Nicholas A. Bellinger wrote:
> > > Or, another options is use bdev_write_zeroes_sectors() to determine
On 05/02/2017 03:42 PM, Jes Sorensen wrote:
> On 04/28/2017 01:05 AM, NeilBrown wrote:
>>
>> When an array is created the content is not initialized,
>> so it could have remnants of an old filesystem or md array
>> etc on it.
>> udev will see this and might try to activate it, which is almost
>>
On 05/02/2017 03:40 PM, Jes Sorensen wrote:
> On 05/02/2017 07:40 AM, Peter Rajnoha wrote:
>> On 05/01/2017 06:35 AM, NeilBrown wrote:
>>> On Fri, Apr 28 2017, Peter Rajnoha wrote:
Then mdadm opens the devive, clears any old content/signatures the data
area may contain, then closes it -
On 05/02/2017 03:32 PM, Jes Sorensen wrote:
> On 04/28/2017 05:28 AM, Peter Rajnoha wrote:
>> On 04/28/2017 07:05 AM, NeilBrown wrote:
>>>
>>> When an array is created the content is not initialized,
>>> so it could have remnants of an old filesystem or md array
>>> etc on it.
>>> udev will see
On 04/28/2017 01:05 AM, NeilBrown wrote:
When an array is created the content is not initialized,
so it could have remnants of an old filesystem or md array
etc on it.
udev will see this and might try to activate it, which is almost
certainly not what is wanted.
So create a mechanism for mdadm
On Tue, 2017-05-02 at 09:23 +0200, h...@lst.de wrote:
> On Tue, May 02, 2017 at 12:16:13AM -0700, Nicholas A. Bellinger wrote:
> > Or, another options is use bdev_write_zeroes_sectors() to determine when
> > dev_attrib->unmap_zeroes_data should be set.
>
> Yes, that in combination with your patch
On 05/02/2017 07:40 AM, Peter Rajnoha wrote:
On 05/01/2017 06:35 AM, NeilBrown wrote:
On Fri, Apr 28 2017, Peter Rajnoha wrote:
Then mdadm opens the devive, clears any old content/signatures the data
area may contain, then closes it - this generates the third event -
which is the "synthetic
On 04/28/2017 05:28 AM, Peter Rajnoha wrote:
On 04/28/2017 07:05 AM, NeilBrown wrote:
When an array is created the content is not initialized,
so it could have remnants of an old filesystem or md array
etc on it.
udev will see this and might try to activate it, which is almost
certainly not
12 matches
Mail list logo