public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "Artem B. Bityutskiy" <dedekind@yandex.ru>
To: Bernhard Priewasser <priewasser@gmail.com>
Cc: MTD mailing list <linux-mtd@lists.infradead.org>
Subject: Re: GC operation
Date: Wed, 09 Nov 2005 17:47:40 +0300	[thread overview]
Message-ID: <43720C0C.2040905@yandex.ru> (raw)
In-Reply-To: <4371F867.6060301@gmail.com>

Bernhard Priewasser wrote:
>> Suppose we have an almost full partition. You write N bytes. There is 
>> only M free space, M < N. If there is N-M of dirty space, GC is 
>> started. Otherwise, -ENOSPC. GC will work until there is enough space 
>> to write. No need to GC the whole partition... Only if the dirty space 
>> is distributed over it, then yes. And yes, the more data is on the FS, 
>> the less is the GC performance and the greater is the average latency...
>>
>> Or, since blocks to GC are picked randomly, we may end up with GC of 
>> the whole partition, hypothetically, but unlikely.
> 
> OK. Things become more clearly. A write request to an almost full 
> partition always issues garbage collecting just as much space (nodes) 
> which is neccessary for writing the new data? And full GC is performed 
> only at mount? (And if c->resv_blocks_gctrigger is reached?)
Not almost full partition. Here are some statements:

1. GC starts if there are no *free eraseblocks*.
2. GC makes free space in units of an eraseblock.
3. No GC is needed on mount.

JFFS2 does *checking* on mount, i.e., checks all CRCs. It is done in the 
context of the GC thread, but does not actually relate to the Garbage 
Collection. This is just how it is implemented.

>>> jffs2_erase_pending_blocks(), am I right? When is it called? I can only
>>> find it in jffs2_write_super() with count=0 and jffs2_find_nextblock()
>>> with count=1.
>>
>> So, you've answered your question :-)
> 
> I meant the way it is called by kupdated (which I don't know at all).
Will just add to what Josh said.

jffs2_write_super() is called when the JFFS2 superblock is dirty 
(JFFS2's sb->s_dirt is set). JFFS2 marks its "struct superblock" 
structure as dirty when something is added to the erase_pending_list or 
written to the wbuf.

When sb->s_dirt, kupdated will call jffs2_write_super() in some 
configurable time and JFFS2 will erase pending eraseblocks and flush the 
wbuf.

I'm not sure why JFFS2 does not use its own timer for this. But it seems 
it used to.

-- 
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.

  parent reply	other threads:[~2005-11-09 14:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-03 16:22 GC operation Bernhard Priewasser
2005-11-03 16:33 ` Artem B. Bityutskiy
2005-11-07 12:47   ` Bernhard Priewasser
2005-11-08 14:31     ` Artem B. Bityutskiy
2005-11-09 13:23       ` Bernhard Priewasser
2005-11-09 13:41         ` Josh Boyer
2005-11-09 14:47         ` Artem B. Bityutskiy [this message]
2005-11-09 17:35           ` Bernhard Priewasser

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=43720C0C.2040905@yandex.ru \
    --to=dedekind@yandex.ru \
    --cc=linux-mtd@lists.infradead.org \
    --cc=priewasser@gmail.com \
    /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