From: "Artem B. Bityuckiy" <abityuckiy@yandex.ru>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: JFFS2 an nodes checking
Date: Tue, 28 Sep 2004 21:15:46 +0400 [thread overview]
Message-ID: <41599C42.4030507@yandex.ru> (raw)
In-Reply-To: <1096390699.30942.110.camel@hades.cambridge.redhat.com>
David Woodhouse wrote:
> Yeah, but we _know_ we're going to write to the flash when we write to
> regular files. That's not necessarily intuitively true for FIFOs. You
> expect your data to get to the other end of the FIFO... you don't
> necessarily expect anything to be written to the flash.
>
Josh Boyer wrote:
> Fifos don't really hold data, they are just named pipes. When you write
> to it, it's mostly handled by the VFS. The actual data isn't written
> out by JFFS2. Except that we have to update st_ctime and st_mtime,
> which causes more nodes.
Yes.. I thought in contents of the optimization I spoke about and tried
to understand this problem in that context. I spoke about iget() delay.
But the FIFO issue is another. Ok, thanks for reply!
David Woodhouse wrote:
> On NOR we can scribble over the old nodes with the old mtime/ctime. On
> NAND we can't so we end up with lots of nodes which are _potentially_
> valid and which all have to be compared.
Josh Boyer wrote:
> Because you can't directly obsolete a node on NAND flash (and some weird
> versions of NOR flash as well). So obsolete nodes are actually written
> out to flash instead of just flipping a bit in the existing node.
Yes, I must have guess this myself. :-)
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
next prev parent reply other threads:[~2004-09-28 17:16 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-28 12:29 JFFS2 an nodes checking Artem B. Bityuckiy
2004-09-28 12:37 ` David Woodhouse
2004-09-28 13:17 ` Artem B. Bityuckiy
2004-09-28 13:22 ` David Woodhouse
2004-09-28 13:37 ` Artem B. Bityuckiy
2004-09-28 13:45 ` David Woodhouse
2004-09-28 13:57 ` Artem B. Bityuckiy
2004-09-28 14:04 ` David Woodhouse
2004-09-28 14:26 ` Artem B. Bityuckiy
2004-09-28 14:37 ` David Woodhouse
2004-09-28 14:58 ` Artem B. Bityuckiy
2004-09-28 15:04 ` David Woodhouse
2004-09-28 14:31 ` Josh Boyer
2004-09-28 14:47 ` Artem B. Bityuckiy
2004-09-28 14:58 ` David Woodhouse
2004-09-28 16:48 ` Artem B. Bityuckiy
2004-09-28 16:57 ` Josh Boyer
2004-09-28 16:58 ` David Woodhouse
2004-09-28 17:15 ` Artem B. Bityuckiy [this message]
2004-09-28 18:24 ` Josh Boyer
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=41599C42.4030507@yandex.ru \
--to=abityuckiy@yandex.ru \
--cc=dwmw2@infradead.org \
--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.