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 10:44:38 +0200 [thread overview]
Message-ID: <557555F6.4030009@nod.at> (raw)
In-Reply-To: <1433752038-17276-1-git-send-email-yangds.fnst@cn.fujitsu.com>
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?
> (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.
Thanks,
//richard
next prev parent reply other threads:[~2015-06-08 8:45 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 [this message]
2015-06-08 9:11 ` Dongsheng Yang
2015-06-08 9:33 ` Richard Weinberger
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=557555F6.4030009@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.