Re: [PATCH] ubifs: Introduce a mount option of force_atime.

[Dongsheng Yang <yangds.fnst@cn.fujitsu.com>]

On 06/08/2015 05:33 PM, Richard Weinberger wrote:
> Am 08.06.2015 um 11:11 schrieb Dongsheng Yang:
>> On 06/08/2015 04:44 PM, Richard Weinberger wrote:
>>> Am 08.06.2015 um 10:27 schrieb Dongsheng Yang:
>>>> Currently, ubifs does not support access time anyway. I understand
>>>> that there is a overhead to update inode in each access from user.
>>>>
>>>> But for the following two reasons, I think we can make it optional
>>>> to user.
>>>>
>>>> (1). More and more flash storage in server are trying to use ubifs,
>>>> it is not only for a device such as mobile phone any more, we want
>>>> to use it in more and more generic way. Then we need to compete
>>>> with some other main filesystems. From this point, access time is
>>>> necessary to us, at least as a choice to user currently.
>>>
>>> Do you have a reference? I know that modern servers use a lot of SSDs
>>> which use internally NAND (mostly MLC and TLC).
>>> But which systems use RAW NAND where they would care about the atime?
>>
>> Hi Richard,
>>
>> Thanx for your quick response here.
>>
>> http://www.slideshare.net/FujitsuTS/bos-c113a-data-will-change-business-but-will-it-really-change-ict
>> I am not sure is that url available to you. But that's what my team is
>> focus on. It's about a server-using NAND device.
>
> So, you want to use UBI/UBIFS on NAND attached via PCEe?
> Is this SLC NAND? (UBI and UBIFS was designed with SLC in mind).
> MLC and TLC are a major challenge for UBI/UBIFS.

It's SLC.
>
>>>
>>>> (2). The default mount option about atime is relatime currently,
>>>> it's much relaxy compared with strictatime. Then we don't update
>>>> the inode in any accessing. So the overhead is not too much.
>>>> It's really acceptable.
>>>
>>> Did you consider ext4's lazytime? I can think of something like that
>>> for UBIFS too.
>>
>> Yes, lazytime is much better in our usecase, from what I know,
>> they are trying to implement a lazytime in vfs.
>>
>> But what I am doing here is just making the atime possible to user. It
>> means the force_atime is not in the same level with relatime,
>> strictatime and lazytime. force_atime here is just making our ubifs
>> supporting access time in any mode as you chose. If you want to use
>> relatime or strictatime, even or lazytime in future, for ubifs, you
>> have to enable force_atime at first. otherwise we does not support access atime anyway.
>
> Let's name is "enable_atime" instead of "force_atime".

En, good idea.
> The question is, how much will regular "atime" and "relatime" hurt the NAND.
> Do you have numbers?

Actually, I did not do a measure in deep for it. I just did some test
in reading and writing. That turned out no performance problem from my
simple testing.

Thanx
Yang
>
> Thanks,
> //richard
> .
>