From: Estelle HAMMACHE <estelle.hammache@st.com>
To: "Artem B. Bityuckiy" <dedekind@yandex.ru>
Cc: linux-mtd@lists.infradead.org
Subject: Re: atomic file operations
Date: Thu, 24 Mar 2005 12:59:19 +0100 [thread overview]
Message-ID: <4242AB96.8D95936D@st.com> (raw)
In-Reply-To: 42429C1C.8050600@yandex.ru
Hi Artem,
"Artem B. Bityuckiy" wrote:
>
> Estelle HAMMACHE wrote:
> > Yes, when I write that the input buffer is split it means that
> > several data nodes are written to the flash - each data node
> > is an independent piece of data complete with header and CRC.
> > If a data node is only partly written to flash, its CRC check
> > will fail so the partial data will not be taken into account
> > when building the file at next mount. In this sense each data
> > node is an atomic write - but JFFS2 does not guarantee that
> > a write() input buffer will be written as a single data node.
>
> But if you:
>
> 1. write only 0-PAGE_SIZE bytes;
> 2. do not overlap n*PAGE_SIZE borders (n is 1,2, ...)
> 3. do fsync after write.
>
> then you have the guarantee that you either have written all or
> nowthing. JFFS2 does guarantee that due to its implementation.
This is not what I understand from jffs2_write_inode_range.
When you reach the end of the block your data may be split at
any offset because jffs2_reserve_space may return more than
JFFS2_MIN_DATA_LEN but less than the data size (or not enough
space to compress the whole input buffer if you use compression).
Or is there some trick here that I don't understand ??
bye
Estelle
next prev parent reply other threads:[~2005-03-24 11:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-22 21:57 atomic file operations Sergei Sharonov
2005-03-23 9:39 ` Estelle HAMMACHE
2005-03-23 20:50 ` Sergei Sharonov
2005-03-24 10:11 ` Estelle HAMMACHE
2005-03-24 10:53 ` Artem B. Bityuckiy
2005-03-24 11:59 ` Estelle HAMMACHE [this message]
2005-03-24 12:17 ` Artem B. Bityuckiy
2005-03-24 17:28 ` Sergei Sharonov
2005-03-24 19:32 ` Artem B. Bityuckiy
2005-03-24 22:00 ` David Woodhouse
2005-03-25 8:18 ` Artem B. Bityuckiy
2005-03-24 21:59 ` David Woodhouse
2005-03-25 16:18 ` Sergei Sharonov
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=4242AB96.8D95936D@st.com \
--to=estelle.hammache@st.com \
--cc=dedekind@yandex.ru \
--cc=linux-mtd@lists.infradead.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 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.