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 21:18:28 +0200	[thread overview]
Message-ID: <576C3604.1050401@nod.at> (raw)
In-Reply-To: <CAOMqctTpTsTHd8tbVeA+X8bR0KQ77mufw4koDtwZV7rFquQ5xw@mail.gmail.com>

Am 23.06.2016 um 19:55 schrieb Michal Suchanek:
> On 23 June 2016 at 19:34, Richard Weinberger <richard@nod.at> wrote:
>> 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.
> 
> I would collect garbage when the unusable space is some % of free
> space or when the free space is less than a few blocks rather than
> based on time. Nonetheless, it can happen that some of the data the GC
> copied to fresh blocks gets deleted before new blocks are written.
> 
>>
>>> Is it possible to set a parameter somewhere that would make UBIFS do this?
>>
>> Do we really need this?
> 
> Waiting until the space is 0 probably hurts performance in general and
> not only in the specific case of synchronous writes. I did not
> benchmark flash writing, though.

Well, changing the semantics when GC runs is rather easy.
So feel free to do experiments. If we can do better, we'll find
a way to implement it.

Thanks,
//richard

      parent reply	other threads:[~2016-06-23 19:18 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
     [not found]           ` <CAOMqctTpTsTHd8tbVeA+X8bR0KQ77mufw4koDtwZV7rFquQ5xw@mail.gmail.com>
2016-06-23 19:18             ` Richard Weinberger [this message]

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=576C3604.1050401@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.