From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from b.ns.miles-group.at ([95.130.255.144] helo=radon.swed.at) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1bG8Wy-0004Hp-Av for linux-mtd@lists.infradead.org; Thu, 23 Jun 2016 17:35:09 +0000 Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mnViaWZzOlF1ZXN0aW9ucyBBYm91dCBHYXJiYWdl?= =?UTF-8?Q?_Collection?= To: Michal Suchanek References: <5766D0CA.3090404@nod.at> Cc: =?UTF-8?B?6L6J5bCR?= , "linux-mtd@lists.infradead.org" From: Richard Weinberger Message-ID: <576C1DB1.1080002@nod.at> Date: Thu, 23 Jun 2016 19:34:41 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Am 23.06.2016 um 19:20 schrieb Michal Suchanek: > Hello, > > On 19 June 2016 at 19:05, Richard Weinberger 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