Re: Freeze the FUSE on Wubi

[Nick Davies <nickavies@yahoo.com>]

Hi,
> Hi.
> 
> Nick Davies wrote:
> >> Hi.
> >>
> >> Stefan Seyfried wrote:
> >>> On Fri, 16 Oct 2009 01:54:10 -0700 (PDT)
> >>> Nick Davies wrote:
> >>>
> >>>> Dear all,
> >>>>
> >>>>    I am trying to debug the suspend/hibernate on Wubi(The Ubuntu
> >>>> installer for Windows) these day. Since Ubuntu sits on top of NTFS
> >>>> partition with the help of ntfs-3g via FUSE, I think it should not
> >>>> pass the file system freezing stage, but in fact, the suspend works
> >>>> well on my machine. So  I am curious that how can they achieve that?
> >>>> Just keep the FUSE alive to the end of the suspend? Any ideas are
> >>>> welcome.
> >>> (Disclaimer: all below is AFAIK and it might be slightly wrong)
> >>> On swapon(), a block map of the file / partition is made by the kernel
> >>> and later I/O to the swap area are not going through the filesystem
> >>> layer. So FUSE is not involved in the suspend process at the stage of
> >>> image writing.
> >> It's exactly right.
> > Hi,
> > 
> >   Thanks for all your quick response. That is to say, the suspend itself has 
> no conflict with the FUSE when do the freezing?
> >  
> > To Nigel,
> >   I've tried the TuxOnIce project, unfortunately I can't do suspend now. 
> According to the dmesg log, it hangs at the freezing file system. 
> >   I check some codes of your patch. You've patched freeze_filesystems() to the 
> fs/buffer.c file, so I guess there may be something wrong with the freeze order 
> in that subroutine with my situation(OS sits on top of NTFS using ntfs-3g via 
> FUSE). How your opinions?
> 
> Hmm. That's interesting - I'd expect things to be the other way around.
> 
> Can you provide the dmesg?

Actually, my test machine hangs, I just write down some debug info on screen by hands:
"...
 ...
 [  364.413692] Considering devpts.: (root f6c03750, bdev 0)<6>Nope.
 [  364.413700] Considering inotifyfs.: (root f6c04900, bdev 0)<6>Nope.
 [  364.413707] Considering tmpfs.: (root f6c04240, bdev 0)<6>Nope.
 [  364.413714] Considering anon_inodefs.: (root f6c03090, bdev 0)<6>Nope.
 [  364.413722] Considering pipefs.: (root f6c03000, bdev 0)<6>Nope.
 [  364.413729] Considering debugfs.: (root f6c02480, bdev 0)<6>Nope.
 [  364.413737] Considering sockfs.: (root f6c02360, bdev 0)<6>Nope.
"
 So I guess the freezing filesystem has met some troubles.

 If you want me to do more tests, please let me know.

Best regards,
Nick