All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Dongsheng Yang <yangds.fnst@cn.fujitsu.com>,
	adrian.hunter@intel.com, dedekind1@gmail.com
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH] ubifs: Introduce a mount option of force_atime.
Date: Mon, 08 Jun 2015 11:33:32 +0200	[thread overview]
Message-ID: <5575616C.5090504@nod.at> (raw)
In-Reply-To: <55755C48.4080802@cn.fujitsu.com>

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.

>>
>>> (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".
The question is, how much will regular "atime" and "relatime" hurt the NAND.
Do you have numbers?

Thanks,
//richard

  reply	other threads:[~2015-06-08  9:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-08  8:27 [PATCH] ubifs: Introduce a mount option of force_atime Dongsheng Yang
2015-06-08  8:44 ` Richard Weinberger
2015-06-08  9:11   ` Dongsheng Yang
2015-06-08  9:33     ` Richard Weinberger [this message]
2015-06-08  9:54       ` Dongsheng Yang
2015-06-08 10:02         ` Richard Weinberger
2015-06-08 10:03           ` Dongsheng Yang
2015-06-08  9:33 ` Artem Bityutskiy
2015-06-08  9:55   ` Dongsheng Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5575616C.5090504@nod.at \
    --to=richard@nod.at \
    --cc=adrian.hunter@intel.com \
    --cc=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=yangds.fnst@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.