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: <CAOi1vP8eLcc6u-XhpSu33+3eDygy3Mp+_tJXT7ygdwsnUs-RmQ@mail.gmail.com>
Date:   Fri, 23 Mar 2018 10:31:45 +0100
From:   Ilya Dryomov <idryomov@...il.com>
To:     亀井仁志 / KAMEI,HITOSHI 
        <hitoshi.kamei.xm@...achi.com>
Cc:     Dongsheng Yang <dongsheng.yang@...ystack.cn>,
        "sage@...hat.com" <sage@...hat.com>,
        "elder@...nel.org" <elder@...nel.org>,
        "ceph-devel@...r.kernel.org" <ceph-devel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Re: [PATCH 1/2] rbd: RBD_DEV_FLAG_THICK rbd_dev_flags bit

On Thu, Mar 22, 2018 at 12:57 PM, 亀井仁志 / KAMEI,HITOSHI
<hitoshi.kamei.xm@...achi.com> wrote:
> Hi Yang,
>
>> I am not sure is this the best way for this case, what about adding an option in "rbd map -o thick rbd/test"?
>
> I will add such option to the rbd map command to manipulate image settings. So, the end-user
> do not change the settings directly via sysfs file.
>
>>       @@ -4011,6 +4012,15 @@ static void rbd_queue_workfn(struct work_struct *work)
>>                       goto err;
>>               }
>>
>>       +       /* Ignore/skip discard requests for thick-provision image */
>>
>> Just ignore? or return -EOPNOTSUPP?
>
> Thanks, I think -EOPNOTSUPP is better because user programs cannot know
> the result of requested operation when the kernel rbd driver ignores
> discard request. The result of requested operation when the kernel rbd driver
> ignores discard requests, which probably misleads the user programs.
>
>> In addition, we should not ignore the REQ_OP_WRITE_ZEROES.
>
> Relating to the above, the return code of REQ_OP_WRITE_ZEROS request
> is also -EOPNOTSUPP instead of ignoring. I think the result of
> -EOPNOTSUPP is also better for this request because the kernel
> rbd driver can expect that user programs write zero data by itself.

REQ_OP_WRITE_ZEROES should continue to work, we just need to make
sure it never issues truncates or deletes and instead writes zeroes
explicitly.

I think we should be explicit about the fact that discard is not
supported instead of accepting the discard request and failing it in
rbd_queue_workfn().  Attached patch is what I have in mind.

Thanks,

                Ilya

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ