All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Michal Suchanek <hramrach@gmail.com>
Cc: 辉少 <wang502742203@qq.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: 回复:ubifs:Questions About Garbage Collection
Date: Thu, 23 Jun 2016 19:34:41 +0200	[thread overview]
Message-ID: <576C1DB1.1080002@nod.at> (raw)
In-Reply-To: <CAOMqctT4Ftef-TTX+cC9HK5Fg4TTe9MDodGbSrJDBmsKBj_NWA@mail.gmail.com>

Am 23.06.2016 um 19:20 schrieb Michal Suchanek:
> Hello,
> 
> On 19 June 2016 at 19:05, Richard Weinberger <richard@nod.at> wrote:
>> Am 19.06.2016 um 18:14 schrieb 辉少:
>>> Thanks for your kind reply!Do you mean that in synchronous/asynchronous mode GC is also finished in synchronous
>>> /asynchronous way as writting is? A more question is,are all dirty spaces collected in the same time in synchronous mode(at this point the caller will be blocked for a long time) while in asynchronous mode dirty spaces will be collected little by little in asynchronous mode when i do not  notice?Thank you!
>>
>> Hmm, I don't fully understand your first question, can you elaborate?
>> As for dirty space, GC will not collect all dirty space. UBIFS tells GC how much free space an operation
>> will take. UBIFS calls this budget. The GC will try to produce as much free space as needed.
>>
> 
> I guess the issue here is that UBIFS appears to do this
> 
>  1) write files while there is space
>  2) when space is 0 perform a GC run as part of write operation
> 
> when writes are synchronous the GC run is timed as part of the write.

Exactly. :-)

> If GC was asynchronous it would not appear as part of the synchronous
> write operation and would not cause as much write time jitter. When
> mounting a filesystem synchronous having GC synchronous is likely not
> what the user asked for. It's part of the internal fs bookkeeping and
> not part of the operation the user wants to perform synchronously.
> 
> For GC to run asynchronously it would have to start before the
> available space is 0 so writes can still happen.

How would the GC know how much space you need in future?
Sure, we would run the GC every X seconds/minutes/whatever but then the flash will wear out
faster since GC will always run and not only when you really need space.

> Is it possible to set a parameter somewhere that would make UBIFS do this?

Do we really need this? If your application behaves
correctly there is no need to mount the filesystem synchronous.

Thanks,
//richard

  parent reply	other threads:[~2016-06-23 17:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-19 13:56 ubifs:Questions About Garbage Collection =?gb18030?B?u9TJ2Q==?=
2016-06-19 14:50 ` Richard Weinberger
     [not found]   ` <tencent_7ADEA65732A2B069166D1A41@qq.com>
2016-06-19 17:05     ` 回复:ubifs:Questions " Richard Weinberger
     [not found]       ` <CAOMqctT4Ftef-TTX+cC9HK5Fg4TTe9MDodGbSrJDBmsKBj_NWA@mail.gmail.com>
2016-06-23 17:34         ` Richard Weinberger [this message]
     [not found]           ` <CAOMqctTpTsTHd8tbVeA+X8bR0KQ77mufw4koDtwZV7rFquQ5xw@mail.gmail.com>
2016-06-23 19:18             ` Richard Weinberger

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=576C1DB1.1080002@nod.at \
    --to=richard@nod.at \
    --cc=hramrach@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=wang502742203@qq.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 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.