From: "Artem B. Bityuckiy" <abityuckiy@yandex.ru>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: inode checkpoints
Date: Mon, 04 Oct 2004 17:46:10 +0400 [thread overview]
Message-ID: <41615422.8060909@yandex.ru> (raw)
In-Reply-To: <1096895892.30942.614.camel@hades.cambridge.redhat.com>
>>I think the checkpoints shouldn't be created by GC (when it is actually
>>garbage collecting) because of it will decrease the JFFS2 performance.
>>GC is called on some write request when there is no space (excluding the
>>situation when it is called in background by the GC thread). This, it is
>>bad to load GC by additional work of creating checkpoints since it is
>>long enough process....
>>
>>What do you think?
>
>
> Hmmm. Maybe. But we can write a checkpoint node when we GC a previous
> checkpoint node perhaps? And we can still write checkpoint nodes when
> appropriate from the actual JFFS2 write routines.
>
I have the following reasons why it is bad to include checkpoint
writings when garbage collecting:
1. If there is no (or few) space and the GC is called, it is better to
*obsolete* checkpoints, not to create new ones. :-) So, if there are no
threads, I don't know how to create checkpoints from GC... In this case
it is better to create them while writing... But this is additional
delay for write operations...
So, I propose either:
1. Introduce the option which enables the checkpoint support and
automatically enables the GC thread.
2. Just use distinct thread for checkpoints.
Do you have other ideas?
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
next prev parent reply other threads:[~2004-10-04 13:46 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 [this message]
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=41615422.8060909@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.