All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.