From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?B?SsO2cm4=?= Engel Subject: Re: [RFC][PATCH] ChunkFS: fs fission for faster fsck Date: Sat, 28 Apr 2007 12:03:20 +0200 Message-ID: <20070428100319.GA25493@lazybastard.org> References: <17965.60841.900376.524639@gargle.gargle.HOWL> <17966.23512.363955.141489@gargle.gargle.HOWL> <462E7C47.8080604@ksu.edu> <20070425105434.GX32602149@melbourne.sgi.com> <20070425230344.GC16129@nifty> <20070426084738.GA21666@atrey.karlin.mff.cuni.cz> <20070427050742.GC20286@nifty> <20070427105334.GB22949@lazybastard.org> <20070428065006.GA21945@nifty> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Jan Kara , David Chinner , Amit Gud , Nikita Danilov , David Lang , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, riel@surriel.com, zab@zabbo.net, arjan@infradead.org, suparna@in.ibm.com, brandon@ifup.org, karunasagark@gmail.com To: Valerie Henson Return-path: Received: from lazybastard.de ([212.112.238.170]:40812 "EHLO longford.lazybastard.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754710AbXD1KHr (ORCPT ); Sat, 28 Apr 2007 06:07:47 -0400 Content-Disposition: inline In-Reply-To: <20070428065006.GA21945@nifty> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, 27 April 2007 23:50:06 -0700, Valerie Henson wrote: >=20 > Any mapping structure will have to be pre-allocated. How much space would you allocate for it then? The required size surel= y depends on the file size and fragmentation. > So in my secret heart of hearts, I do indeed hope that cnodes are rar= e > enough that we don't actually have to do anything smart to make them > go fast. Either having no fast lookup structure or creating it in > memory as needed would be the nicest solution. However, since I can'= t > guarantee this will be the case, it's nice to have some idea of what > we'll do if this does become important. You go slow and slower. Or you can defragment/clean the filesystem. =46ragmented filesystems being slow is hardly news to anyone. ChunkFS will be slower than others, so the reasons to fight fragmentation weigh heavier. What you can do: - If two files 1 and 2 contain blocks in chunks A and B, move file 1 blocks to chunk A and file 2 blocks to chunk B until one of the files only spans a single chunk. - Same as above with longer chains like file 1 in chunks (A,B), file 2 in chunks (B,C), file 3 in chunks (A,C). - When writing to file 1 in chunk A but running out of space in chunk A= , move some cross-chunk file over instead of writing file 1 blocks to chunk B. The first two can hope to use some idle times (if they exist), the thir= d will make writes go slower in order to speed up future reads. There ain't no such thing as a free lunch. :) J=C3=B6rn --=20 I can say that I spend most of my time fixing bugs even if I have lots of new features to implement in mind, but I give bugs more priority. -- Andrea Arcangeli, 2000 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html