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

[Andreas Dilger]

On 2010-03-21, at 20:12, Matt Helsley wrote:
> These are the same kinds of problems encountered during backup. You
> can play fast and loose -- like taking a backup while everything is
> running -- or you can play it conservative and freeze things.
>
> I think btrfs snapshots are just one possible solution and it's not
> overkill.
>
> For some filesystems it might make sense to use the filesystem  
> freezer to
> ensure that no files are deleted while the backup takes place.  
> Combined
> with tools like rsync or rdiff backup these operations could be low  
> bandwidth
> and low latency if well-known live-migration techniques are used.
>
> Or use dm snapshots.


If you are using snapshots, then even an open-unlinked file will not  
be deleted from the filesystem until it is closed, because the inode  
will still be available on disk even without the filename.  That would  
be a good reason to also store the file handle (e.g. inode+generation  
for simple filesystems) in the checkpoint file, so that you can re- 
open this file by the file handle after the process is restarted.

Since Aneesh is starting to add an interface for this to the kernel  
anyway, I don't think it would be very hard to dump/restore a handful  
of extra bytes with each file.  Conversely, now is the time for  
getting the open-by-handle APIs correct for this code.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers