From: "Artem B. Bityuckiy" <abityuckiy@yandex.ru>
To: "Artem B. Bityuckiy" <abityuckiy@yandex.ru>
Cc: linux-mtd@lists.infradead.org, David Woodhouse <dwmw2@infradead.org>
Subject: Re: inode checkpoints
Date: Sat, 09 Oct 2004 15:58:10 +0400 [thread overview]
Message-ID: <4167D252.2040207@yandex.ru> (raw)
In-Reply-To: <4167CF42.3030506@yandex.ru>
Artem B. Bityuckiy wrote:
> Hello Guys.
>
> Unfortunately, I hit on very painful trouble while trying to
> design/implement checkpoints (ICP) ...
>
> Obviously, ICP must contain all information, which is required to build
> the inode cache. These are: offset, size and *version*. The problem is
> in version.
>
> At first I thought that in order to create ICP for some regfile inode,
> we just need to be sure that the inode cache for this regfile exists.
> But! I've overseen the fact that *there is no versions in the inode
> cache* :-(
>
> The inode cache (struct jffs2_inode_info) contains fragtree which has
> struct jffs2_full_dnode objects. But these objects have no version field...
>
> So, I see two ways out:
>
> 1. Add the version field to the struct jffs2_full_dnode objects.
> This also means that the struct jffs2_tmp_dnode_info structure won't be
> needed anymore.
>
> The advantage of such approach is that the JFFS2 will be more simple
> since one data structure will be removed. I like the KISS principle.
>
> The drawback is that the inode cache will eat more memory. But this
> isn't in-core object, just cache, so I don't think this is a big
> disadvantage.
>
> 2. Don't use the inode cache at all
when building ICP.
> This is bad because in order to
> build the inode cache
> soory, not inode cache, I meant "build ICP"
> we'll need to read *all* the node headers, even if
> there is existing inode cache.
>
> I believe this approach is bad and too heavyweight. Moreover, just
> imagine the situation when the GC has fount an ICP ant wants to
> determine if it valid or obsolete. Obsolete means that (1) there is
> newer ICP with higher version (simple case) or (2) all (or most) the
> nodes which are described by the ICP aren't valid anymore (complicated
> case). The second case means that we must read the ICPs lowest_version
> and highest_version and count how many valid nodes with versions within
> this interval exist. But we have NO versions even if the inode cache is
> present. I don't think it is a good idea if the GC will head all the
> node's headers...
>
> What do you guys think? Any advices/ideas?
>
> Thanks.
>
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
next prev parent reply other threads:[~2004-10-09 11:59 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-04 10:14 inode checkpoints Artem Bityuckiy
2004-10-04 10:22 ` David Woodhouse
2004-10-04 10:36 ` [OBORONA-SPAM] " Artem B. Bityuckiy
2004-10-04 12:34 ` Josh Boyer
2004-10-04 13:07 ` Artem B. Bityuckiy
2004-10-04 13:18 ` David Woodhouse
2004-10-04 13:32 ` Artem B. Bityuckiy
2004-10-04 13:46 ` Artem B. Bityuckiy
2004-10-04 14:18 ` Artem B. Bityuckiy
2004-10-04 14:23 ` David Woodhouse
2004-10-04 15:07 ` Artem B. Bityuckiy
2004-10-05 14:07 ` Artem B. Bityuckiy
2004-10-05 16:45 ` David Woodhouse
2004-10-05 17:20 ` Josh Boyer
2004-10-06 9:07 ` Artem B. Bityuckiy
2004-10-09 11:45 ` Artem B. Bityuckiy
2004-10-09 11:58 ` Artem B. Bityuckiy [this message]
2004-10-09 13:01 ` Artem B. Bityuckiy
2004-10-09 14:48 ` Artem B. Bityuckiy
2004-10-09 13:22 ` Artem B. Bityuckiy
2004-10-04 11:44 ` Artem Bityuckiy
2004-10-04 12:36 ` Josh Boyer
2004-10-04 12:43 ` David Woodhouse
2004-10-04 13:26 ` [OBORONA-SPAM] " Artem B. Bityuckiy
2004-10-04 13:39 ` Josh Boyer
2004-10-04 13:56 ` Artem Bityuckiy
2004-10-04 14:06 ` Artem B. Bityuckiy
2004-10-04 14:17 ` Josh Boyer
2004-10-04 14:22 ` Artem B. Bityuckiy
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=4167D252.2040207@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.