From: Aleksandr Koltsoff <aleksandr.koltsoff@ebts.fi>
To: linux-kernel@vger.kernel.org
Subject: RFC: Exporting NOCMTIME to userspace
Date: Mon, 21 Jun 2010 09:36:46 +0300 [thread overview]
Message-ID: <4C1F087E.7070000@ebts.fi> (raw)
Hello all,
I'm currently investigating various techniques to lessen the block erase
load on consumer nand flash devices (usb-ftl + nand and sd-ftl + nand).
While SSDs are of no current interest to me, this use case applies to
them as well.
The use case I'm working with is a set of pre-allocated files that get
updated periodically with data that overwrites some of the existing
data. The files never grow/shrink. (rrdtool is a good example of such
behaviour).
I've been looking for a mechanism to avoid writes going to the inodes of
the files, but have been unsuccessful so far. At least ctime will get
updated periodically.
In this use case, the timestamps are really irrelevant (the file content
contains timestamps), and I'd like to avoid updating the inodes
all-together. What happens now is extra block erasures when they aren't
actually needed or wanted.
While there is a flag in the inode structure to stop m/ctime updates,
this flag is not currently exported to userspace (similar to O_NOATIME).
I feel that the least intrusive way would be such a flag, since this is
certainly an application/file-specific problem and a mount-point flag
would be not so useful.
How do people feel about this? I'm aware of some of the ramifications of
not updating ctime (regarding dumping filesystem changes, and making
life more difficult for rsync/mtime-based backups). However, I still
feel quite strongly that providing an option for applications to avoid
extra nand erases would be a good thing.
On the other hand, if someone can suggest a way to avoid timestamp
updates/causing inode writes, I'm all ears and eyes. (using the
block-layer directly or writing a custom fs is not really an elegant
solution, IMO).
Thank you for your time & best regards,
Aleksandr Koltsoff
next reply other threads:[~2010-06-21 6:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-21 6:36 Aleksandr Koltsoff [this message]
2010-06-21 8:56 ` RFC: Exporting NOCMTIME to userspace Andi Kleen
2010-06-21 9:12 ` Aleksandr Koltsoff
2010-06-21 10:32 ` Andi Kleen
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=4C1F087E.7070000@ebts.fi \
--to=aleksandr.koltsoff@ebts.fi \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox