[C/R v20][PATCH 38/96] c/r: dump open file descriptors

[Daniel Lezcano]

Serge E. Hallyn wrote:
> Quoting Jamie Lokier (jamie at 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.
>