From: "Artem B. Bityuckiy" <abityuckiy@yandex.ru>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [OBORONA-SPAM] Re: inode checkpoints
Date: Mon, 04 Oct 2004 14:36:39 +0400 [thread overview]
Message-ID: <416127B7.3070505@yandex.ru> (raw)
In-Reply-To: <1096885344.30942.559.camel@hades.cambridge.redhat.com>
> It seems to make a lot of sense. We could write such checkpoints only on
> files which are large enough to warrant them, and we could tune the
> frequency of such checkpoints.
The following are required features (as I think) of the checkpoint
creation algorithm and strategy.
1 New checkpoint nodes must not be created if there is little free space
left on the file system.
2 New checkpoint nodes ought to be created only for large inodes.
3 The checkpoint nodes creation process must not decrease the JFFS2
performance very much.
Checkpoints should be created in background by the GC thread. GC begins
creating checkpoints if the following is true:
1 there is no other work to do for GC (i.e., there is no need to check
inodes and to garbage collect the dirt);
2 there is sufficient amount of free space on the file system
The checkpoint creation process consists of two major steps:
1 locating the most appropriate inode;
2 providing that the inode is found, write the checkpoint(s) for it.
Also, when there are few space left on the file system, GC may begin
obsoleting checkpoints, starting from checkpoints for smaller files,
etc. Thus, the spase may appear.
>
> Of course as with many cute ideas it may turn out to be utterly
> impractical when we implement it :) It does look sane though.
I hope this will be practical if we implement this.
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
next prev parent reply other threads:[~2004-10-04 10:37 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 ` Artem B. Bityuckiy [this message]
2004-10-04 12:34 ` [OBORONA-SPAM] " 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
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=416127B7.3070505@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox