From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263188AbUCMVDZ (ORCPT ); Sat, 13 Mar 2004 16:03:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263189AbUCMVDZ (ORCPT ); Sat, 13 Mar 2004 16:03:25 -0500 Received: from gprs40-159.eurotel.cz ([160.218.40.159]:16328 "EHLO amd.ucw.cz") by vger.kernel.org with ESMTP id S263188AbUCMVDX (ORCPT ); Sat, 13 Mar 2004 16:03:23 -0500 Date: Sat, 13 Mar 2004 22:03:05 +0100 From: Pavel Machek To: =?iso-8859-1?Q?J=F6rn?= Engel Cc: Sytse Wielinga , linux-kernel@vger.kernel.org Subject: Re: [PATCH for testing] cow behaviour for hard links Message-ID: <20040313210305.GB549@elf.ucw.cz> References: <20040310193429.GB4589@wohnheim.fh-wedel.de> <200403121849.03505.s.b.wielinga@student.utwente.nl> <20040312182912.GB7087@wohnheim.fh-wedel.de> <20040313134330.GC3352@openzaurus.ucw.cz> <20040313194827.GA4748@wohnheim.fh-wedel.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20040313194827.GA4748@wohnheim.fh-wedel.de> X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.4i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On So 13-03-04 20:48:27, Jörn Engel wrote: > On Sat, 13 March 2004 14:43:30 +0100, Pavel Machek wrote: > > > > I do not know your current design, but... > > > > In ideal world there would be no COW links. System would > > magically detect that you are doing cp -a, and would link > > at individual block level. > > > > Well, that would be probably too fs-specific. But introducing copyfile() > > syscall, which would just link the inodes if underlying fs > > supported it might be good start. On first > > write into one > > of linked files copy > > would be done... > > Agreed. > > > Only disadvantage I see is that such links would not survive > > tar-backup... > > That's not a problem either. Have a userspace program that checks all > files and hints for identical ones (new syscall, copyfile() cannot do > this without races). Depending on fs size, the necessary data can > grow into the gigabytes, but the code is just 200 lines. Hmm, I don't quite like "copyfile if not modified" syscall, but even without that it is usefull... > Or did you mean the problem of tar backups growing *much* larger than > the real filesystem? Yes, tar becomes useless for backups then. :) Yep, this is what I meant. Pavel -- When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]