On Wed, Jan 13, 2010 at 05:57:40PM +1100, Dave Chinner wrote:
> On Wed, Jan 13, 2010 at 05:05:18PM +1100, Nathan Scott wrote:
> > [Looks like tuxonice is a subscriber-only list...]
> > ----- "Dave Chinner" <david@xxxxxxxxxxxxx> wrote:
> > > On Wed, Jan 13, 2010 at 02:09:14PM +1100, Nathan Scott wrote:
> > > > >
> > > Agreed that it is trivial to implement but there are still some
> > > definite traps - like the fact the sb change transaction may be
> > > logged
> > > immediately but the physical superblock may not get written for some
> > > time after the mount.
> > *nod* ... it will be written when unmounted though...
> suspend in the kernel doesn't unmount filesystems. I have no idea
> what tuxonice does these days, but last time I heard it left them
> mounted but frozen over the suspend/resume cycle.
I found the code - it doesn't unmount filesystems. The git tree is
It appears that it walks the list of superblocks to grab the block
device off each mounted superblock to do it's work, so I don't see
any fundamental problem with using an attribute hanging off
sb->s_root to hold the boot time...