From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Lezcano Subject: Re: [C/R v20][PATCH 38/96] c/r: dump open file descriptors Date: Sun, 21 Mar 2010 21:58:44 +0100 Message-ID: <4BA68884.3080003@free.fr> References: <1268960401-16680-1-git-send-email-orenl@cs.columbia.edu> <1268960401-16680-4-git-send-email-orenl@cs.columbia.edu> <20100320044310.GC2887@count0.beaverton.ibm.com> <20100321172703.GC4174@shareable.org> <20100321194019.GA11714@hallyn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jamie Lokier , linux-fsdevel@vger.kernel.org, containers@lists.linux-foundation.org, Andreas Dilger To: "Serge E. Hallyn" Return-path: Received: from mtagate6.uk.ibm.com ([194.196.100.166]:55979 "EHLO mtagate6.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753443Ab0CUU6z (ORCPT ); Sun, 21 Mar 2010 16:58:55 -0400 Received: from d06nrmr1806.portsmouth.uk.ibm.com (d06nrmr1806.portsmouth.uk.ibm.com [9.149.39.193]) by mtagate6.uk.ibm.com (8.13.1/8.13.1) with ESMTP id o2LKwmtE001122 for ; Sun, 21 Mar 2010 20:58:48 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o2LKwmec1413184 for ; Sun, 21 Mar 2010 20:58:48 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o2LKwlsh020654 for ; Sun, 21 Mar 2010 20:58:48 GMT In-Reply-To: <20100321194019.GA11714@hallyn.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Serge E. Hallyn wrote: > Quoting Jamie Lokier (jamie@shareable.org): > >> Matt Helsley wrote: >> >>>> That said, if the intent is to allow the restore to be done on >>>> another node with a "similar" filesystem (e.g. created by rsync/node >>>> image), instead of having a coherent distributed filesystem on all >>>> of the nodes then the filename makes sense. >>>> >>> Yes, this is the intent. >>> >> I would worry about programs which are using files which have been >> deleted, renamed, or (very common) renamed-over by another process >> after being opened, as there's a good chance they will successfully >> open the wrong file after c/r, and corrupt state from then on. >> > > Userspace is expected to back up and restore the filesystem, for > instance using a btrfs snapshot or a simple rsync or tar. > > That does not solve the problem Jamie is talking about. A rsync or a tar will not see a deleted file and using a btrfs to have the CR to work with the deleted files is a bit overkill, no ? I have another question about the deleted files. How is handled the case when a process has a deleted mapped file but without an associated file descriptor ? > If we detect anything which really is not supported (for instance > inotify for now) then we fail and leave a log message explaining the > failure. >