All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Artem B. Bityuckiy" <dedekind@mail.ru>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: inode checkpoints
Date: Sat, 09 Oct 2004 17:22:32 +0400	[thread overview]
Message-ID: <4167E618.6030503@mail.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.
Ok, guys, sorry, I've hurried saying that the struct 
jffs2_tmp_dnode_info won't be needed... It is needed to construct lists 
of struct jffs2_full_dnode objects...

Anyway, my problem is still actual.

> 
> 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. This is bad because in order to 
> build the inode cache 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. Bityckiy

  parent reply	other threads:[~2004-10-09 13:23 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
2004-10-09 13:01                       ` Artem B. Bityuckiy
2004-10-09 14:48                         ` Artem B. Bityuckiy
2004-10-09 13:22                       ` Artem B. Bityuckiy [this message]
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=4167E618.6030503@mail.ru \
    --to=dedekind@mail.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.