From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roger Larsson Subject: [RFC] Copy on First Read? Date: Mon, 10 Jul 2006 09:04:44 +0200 Message-ID: <200607100904.44983.roger.larsson@norran.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from ns.skekraft.net ([213.199.96.131]:13537 "EHLO mail.skekraft.net") by vger.kernel.org with ESMTP id S1161364AbWGJHEr (ORCPT ); Mon, 10 Jul 2006 03:04:47 -0400 Received: from icd.localnet (78.net216.skekraft.net [84.244.216.78]) by mail.skekraft.net (Postfix) with ESMTP id AF7A2A405D for ; Mon, 10 Jul 2006 09:04:45 +0200 (CEST) To: linux-fsdevel@vger.kernel.org Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org I have been thinking about a file system that uses Copy On First Read. My idea looks like this: 1. Split the disk in three parts (unused, write, used - could be growing from top and bottom like heap and stack) 2. Writes goes to one part - log structured, like a tape. Fragmentation of files are OK, but buffering is done to prevent the worst cases. This to allow fast write of huge amounts of data. Later when the file is first read * the size is known. * is probably read together with other files that in future will be used together. So the allocation rule for the copy on first read can use these facts. Only files that are actually used will be read and thus rewritten. This will leave unused files in the write part. This old files can be compacted to and moved to the 'unused' part to give a continuous area to use as write part. These files could even be moved to a slower media (if available). Log files will remain in 'write/unused' sections until searched. Comments? /RogerL