On 18/06/2020 19:09, Mike Snitzer wrote:
> On Thu, Jun 18 2020 at 12:50pm -0400,
> Sami Tolvanen wrote:
>
>> On Thu, Jun 18, 2020 at 11:44:45AM -0400, Mike Snitzer wrote:
>>> I do not accept that panicing the system because of verity failure is
>>> reasonable.
>>>
>>> In fact, even rebooting (via
On 2020/06/22 16:55, Ignat Korchagin wrote:
> On Mon, Jun 22, 2020 at 1:45 AM Damien Le Moal wrote:
>>
>> On 2020/06/20 1:56, Mike Snitzer wrote:
>>> On Fri, Jun 19 2020 at 12:41pm -0400,
>>> Ignat Korchagin wrote:
>>>
This is a follow up from the long-forgotten [1], but with some more
On 22/06/2020 02:27, Damien Le Moal wrote:
[...]
> Just to be extra sure, I checked this again. Since for zoned block devices the
> mapping of a target must be zoned aligned and a zone append command is always
> fully contained within a zone, we do not need this check. The stacked limits
> and
> s
Hello Dear DM-Verity maintainers.
Thank you for your reply.
I agreed with you that "the device should be put in a failed state and
left for admin recovery"
As dear Sami told us, When Android device occurred panic, restarting and
to save the logs to bootloader also recovery log.
Of course Using t
Hi,
Thanks a lot for your fix and this patchset! It looks better than
before!
Thanks,
Kun.
在 2020/6/20 5:10, Bryan Gurney 写道:
From: yangerkun
From: yangerkun
Some type of message(queryblock/countbadblocks/removebadblock) may better
report results to user directly. Do it with DMEMIT.
[Brya
On Fri, Jun 19, 2020 at 7:39 PM Mikulas Patocka wrote:
>
>
>
> On Fri, 19 Jun 2020, Mike Snitzer wrote:
>
> > On Fri, Jun 19 2020 at 12:41pm -0400,
> > Ignat Korchagin wrote:
> >
> > > This is a follow up from the long-forgotten [1], but with some more
> > > convincing
> > > evidence. Consider t
Yes, it should.
I got one when I was testing the first iteration (without the tasklet)
of the patch on an NVME? disk.
On Sat, Jun 20, 2020 at 8:36 PM Mikulas Patocka wrote:
>
>
>
> On Sat, 20 Jun 2020, Herbert Xu wrote:
>
> > On Fri, Jun 19, 2020 at 02:39:39PM -0400, Mikulas Patocka wrote:
> > >
Sometimes extra thread offloading imposed by dm-crypt hurts IO latency. This is
especially visible on busy systems with many processes/threads. Moreover, most
Crypto API implementaions are async, that is they offload crypto operations on
their own, so this dm-crypt offloading is excessive.
This ad
This is a follow up from the long-forgotten [1], but with some more convincing
evidence. Consider the following script:
#!/bin/bash -e
# create 4G ramdisk
sudo modprobe brd rd_nr=1 rd_size=4194304
# create a dm-crypt device with NULL cipher on top of /dev/ram0
echo '0 8388608 crypt capi:ecb(ciph
On Mon, Jun 22, 2020 at 1:45 AM Damien Le Moal wrote:
>
> On 2020/06/20 1:56, Mike Snitzer wrote:
> > On Fri, Jun 19 2020 at 12:41pm -0400,
> > Ignat Korchagin wrote:
> >
> >> This is a follow up from the long-forgotten [1], but with some more
> >> convincing
> >> evidence. Consider the followin
Dear Milan Broz.
Thank for your reply.
I didn't understand well, could you explain it in more detail?
For what reason isn't panic better?
Is it because there is a place to use other device-mapper?
Or other things? I just wonder. I would like to hear various
explanations and information.
I
11 matches
Mail list logo
