Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 4 Mar 2002 10:33:09 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 4 Mar 2002 10:32:48 -0500 Received: from adsl-63-194-239-202.dsl.lsan03.pacbell.net ([63.194.239.202]:26354 "EHLO mmp-linux.matchmail.com") by vger.kernel.org with ESMTP id ; Mon, 4 Mar 2002 10:32:32 -0500 Date: Mon, 4 Mar 2002 07:33:12 -0800 From: Mike Fedyk To: Alan Cox Cc: James D Strandboge , Linux Kernel Mailing List Subject: Re: ext3 and undeletion Message-ID: <20020304153312.GI353@matchmail.com> Mail-Followup-To: Alan Cox , James D Strandboge , Linux Kernel Mailing List In-Reply-To: <20020304021714.GB353@matchmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 04, 2002 at 03:12:44PM +0000, Alan Cox wrote: > > another inode after the trunc op would break unix semantics. In order to > > work, you'd have to use a new inode (in .undelete, of course), copy, then do > > the actual trunc call. > > This would make truncation expensive, whereas before it was pretty fast. > > Modifying unlink will probably suffice. > > You would need to hook the truncate/unlink paths in the file system. If > you are doing it within the fs it becomes cheap (at least for ext2) - as > you can simply reassign the data blocks to a new inode, stuff the new inode > into the magic "stuff we deleted" directory and continue. It may make it easier to put this part in the kernel, but is there some way to make it filesystem generic? Undelete on truncate isn't a high priority, but if we do have it, it would be nice if all of the filesystems that follow unix semantics (and maybe the others too) could use generic VFS ops for this feature. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/