On Wed, Nov 10, 2021 at 6:14 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Wed, 10 Nov 2021 at 04:43, Hao Peng <flyingpenghao@xxxxxxxxx> wrote: > > > > On Wed, Sep 8, 2021 at 5:27 PM Hao Peng <flyingpenghao@xxxxxxxxx> wrote: > > > > > > On Wed, Sep 8, 2021 at 5:08 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > > > > > On Wed, 8 Sept 2021 at 04:25, Hao Peng <flyingpenghao@xxxxxxxxx> wrote: > > > > > > > > > > On Tue, Sep 7, 2021 at 5:34 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > > > > > > > > > On Mon, 6 Sept 2021 at 14:36, Hao Peng <flyingpenghao@xxxxxxxxx> wrote: > > > > > > > > > > > > > > For a simple read-only file system, as long as the connection > > > > > > > is not broken, the recovery of the user-mode read-only file > > > > > > > system can be realized by putting the request of the processing > > > > > > > list back into the pending list. > > > > > > > > > > > > Thanks for the patch. > > > > > > > > > > > > Do you have example userspace code for this? > > > > > > > > > > > Under development. When the fuse user-mode file system process is abnormal, > > > > > the process does not terminate (/dev/fuse will not be closed), enter > > > > > the reset procedure, > > > > > and will not open /dev/fuse again during the reinitialization. > > > > > Of course, this can only solve part of the abnormal problem. > > > > > > > > Yes, that's what I'm mainly worried about. Replaying the few > > > > currently pending requests is easy, but does that really help in real > > > > situations? > > > > > > > > Much more information is needed about what you are trying to achieve > > > > and how, as well as a working userspace implementation to be able to > > > > judge this patch. > > > > > > > I will provide a simple example in a few days. The effect achieved is that the > > > user process will not perceive the abnormal restart of the read-only file system > > > process based on fuse. > > > > > > > Thanks, > > > > Miklos > > Hi，I have implemented a small test program to illustrate this new feature. > > After downloading and compiling from > > https://github.com/flying-122/libfuse/tree/flying > > #gcc -o testfile testfile.c -D_GNU_SOURCE > > #./example/passthrough_ll -o debug -s /mnt3 > > #./testfile (on another console) > > #ps aux | grep pass > > #root 34889 0.0 0.0 8848 864 pts/2 S+ 13:10 0:00 > > ./example/passthrough_ll -o debug -s /mnt3 > > #root 34896 0.0 0.0 9880 128 pts/2 S+ 13:10 0:00 > > ./example/passthrough_ll -o debug -s /mnt3 > > #root 34913 0.0 0.0 12112 1060 pts/1 S+ 13:10 0:00 > > grep --color=auto pass > > // kill child process > > #kill 34896 > > You will see that ./testfile continues to execute without noticing the > > abnormal restart of the fuse file system. > > This is a very good first example demonstrating the limits of the > recovery. The only state saved is the actual device file descriptor > and the result of the INIT negotiation. > > It works if there are a fixed number of files, e.g. a read only > filesystem, where the files can be enumerated (i.e. a file or > directory can be found based on a single 64bit index) > > Is this your use case? > The version used is more complicated to maintain file/directory information, and is used for the internal read-only file system. As long as the number of files remains the same, it is also possible to write files. I plan to use this recovery method for lxcfs. Thanks. > Are you ever planning to extend this to read-write filesystems? > > Thanks, > Miklos
