* Re: [TuxOnIce-devel] Latest updates. [not found] <2097834991.1721031263351861134.JavaMail.root@mail-au.aconex.com> @ 2010-01-13 3:09 ` Nathan Scott 2010-01-13 5:41 ` Dave Chinner 0 siblings, 1 reply; 6+ messages in thread From: Nathan Scott @ 2010-01-13 3:09 UTC (permalink / raw) To: Martin Steigerwald; +Cc: TuxOnIce Devel List, xfs ----- "Martin Steigerwald" <Martin@lichtvoll.de> wrote: > Please keep CC to TuxOnIce devel list. > > > Hi! > > Nigel, who develops the alternative TuxOnIce hibernation / snapshot > infrastructure, implemented checking last mount time of filesystem as > a > safety feature for Ext 2, 3 and 4. > > He would like this also for XFS. Does XFS record the last mount time > somewhere? Nope. > If not, could this be added? Anythings possible ... its a relatively trivial change, and there's room in the superblock. Could probably even be done without a superblock version bump - if you were prepared to live with the possibility of finding zero in the ondisk location & dealing with it appropriately (i.e. last mount time unknown). Guess you'd have to convince the XFS folks doing most of the work these days, but really it'd be quite trivial to implement. xfs_mount_log_sb() would be the place to start looking... cheers. -- Nathan _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [TuxOnIce-devel] Latest updates. 2010-01-13 3:09 ` [TuxOnIce-devel] Latest updates Nathan Scott @ 2010-01-13 5:41 ` Dave Chinner 2010-01-13 6:05 ` Nathan Scott 0 siblings, 1 reply; 6+ messages in thread From: Dave Chinner @ 2010-01-13 5:41 UTC (permalink / raw) To: Nathan Scott; +Cc: TuxOnIce Devel List, xfs On Wed, Jan 13, 2010 at 02:09:14PM +1100, Nathan Scott wrote: > > ----- "Martin Steigerwald" <Martin@lichtvoll.de> wrote: > > > Please keep CC to TuxOnIce devel list. > > > > > > Hi! > > > > Nigel, who develops the alternative TuxOnIce hibernation / snapshot > > infrastructure, implemented checking last mount time of filesystem as > > a > > safety feature for Ext 2, 3 and 4. > > > > He would like this also for XFS. Does XFS record the last mount time > > somewhere? > > Nope. > > > If not, could this be added? > > Anythings possible ... its a relatively trivial change, and there's room > in the superblock. Could probably even be done without a superblock version > bump - if you were prepared to live with the possibility of finding zero in > the ondisk location & dealing with it appropriately (i.e. last mount time > unknown). > > Guess you'd have to convince the XFS folks doing most of the work these > days, but really it'd be quite trivial to implement. xfs_mount_log_sb() > would be the place to start looking... 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. Really it comes down to the interface used to read the mount time fromt eh superblock at suspend and resume - can anyone tell me what that is or point me at the code? Personally I don't see why this needs to be in the superblock - an extended attribute on the root directory of the root filesystem that is written: a) by a startup script at boot time; b) by the suspend code; c) copied into the suspend image; and d) read and verified during resume seems sufficient to me to provide what you want. This has the benefit of being completely filesystem independent and doesn't require on-disk format changes for every filesystem that ppl want TuxOnIce to supprt. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [TuxOnIce-devel] Latest updates. 2010-01-13 5:41 ` Dave Chinner @ 2010-01-13 6:05 ` Nathan Scott 2010-01-13 6:57 ` Dave Chinner 0 siblings, 1 reply; 6+ messages in thread From: Nathan Scott @ 2010-01-13 6:05 UTC (permalink / raw) To: Dave Chinner; +Cc: TuxOnIce Devel List, xfs [Looks like tuxonice is a subscriber-only list...] ----- "Dave Chinner" <david@fromorbit.com> 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... > > Really it comes down to the interface used to read the mount time > fromt eh superblock at suspend and resume - can anyone tell me what > that is or point me at the code? (not me!) > Personally I don't see why this needs to be in the superblock - an > extended attribute on the root directory of the root filesystem that > is written: Yeah, that was my first thought too, but I suspect they want to be able to query this when the filesystem is unmounted; in which case the interface is probably "read a fs-specific magic spot ondisk". For this not-mounted query, the EA route would be incredibly painful. cheers. -- Nathan _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [TuxOnIce-devel] Latest updates. 2010-01-13 6:05 ` Nathan Scott @ 2010-01-13 6:57 ` Dave Chinner 2010-01-13 8:11 ` Dave Chinner 0 siblings, 1 reply; 6+ messages in thread From: Dave Chinner @ 2010-01-13 6:57 UTC (permalink / raw) To: Nathan Scott; +Cc: TuxOnIce Devel List, xfs On Wed, Jan 13, 2010 at 05:05:18PM +1100, Nathan Scott wrote: > [Looks like tuxonice is a subscriber-only list...] > > ----- "Dave Chinner" <david@fromorbit.com> 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. > > Really it comes down to the interface used to read the mount time > > fromt eh superblock at suspend and resume - can anyone tell me what > > that is or point me at the code? > > (not me!) > > > Personally I don't see why this needs to be in the superblock - an > > extended attribute on the root directory of the root filesystem that > > is written: > > Yeah, that was my first thought too, but I suspect they want to be > able to query this when the filesystem is unmounted; in which case > the interface is probably "read a fs-specific magic spot ondisk". > For this not-mounted query, the EA route would be incredibly painful. I know, but it's the "read from the magic spot on disk" approach that I'm most concerned about. It's so easy to implement, but oh so easy get wrong because block device access is not coherent with the filesystem. Not to mention that if we change the format of the "magic spot" then the application breaks, whereas that will not happen if access is via extended attributes. Essentially, I don't want to see another boot related, filesystem interacting application having random problems with XFS and then doing stupid stuff to try to work around problems caused by fundamentally broken assumptions made by the application. IMO, learning from the mistakes the world's most screwed up bootlader (grub) made is a good idea.... Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [TuxOnIce-devel] Latest updates. 2010-01-13 6:57 ` Dave Chinner @ 2010-01-13 8:11 ` Dave Chinner 2010-01-13 8:44 ` Nigel Cunningham 0 siblings, 1 reply; 6+ messages in thread From: Dave Chinner @ 2010-01-13 8:11 UTC (permalink / raw) To: Nathan Scott; +Cc: TuxOnIce Devel List, xfs 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@fromorbit.com> 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 here: http://git.kernel.org/?p=linux/kernel/git/nigelc/tuxonice-head.git;a=summary 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... Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [TuxOnIce-devel] Latest updates. 2010-01-13 8:11 ` Dave Chinner @ 2010-01-13 8:44 ` Nigel Cunningham 0 siblings, 0 replies; 6+ messages in thread From: Nigel Cunningham @ 2010-01-13 8:44 UTC (permalink / raw) To: Dave Chinner; +Cc: TuxOnIce Devel List, Nathan Scott, xfs Hi. Dave Chinner wrote: > 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@fromorbit.com> 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 > here: > > http://git.kernel.org/?p=linux/kernel/git/nigelc/tuxonice-head.git;a=summary > > 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... Yeah. The idea is to have very simple code that looks at a fixed number of bytes at a known offset into the partition. The value of the bytes is stored in the image header, and compared prior to starting to resume. If the data is different, we assume the filesystem has been mounted since the image was written and it's unsafe to resume. It doesn't _need_ to be a time - just something that's guaranteed to have changed if the filesystem gets mounted afresh. By the way, sorry for the slow replies so far and for slow ones in the coming 24 hours. I'm on holidays and my father-in-law's funeral is tomorrow. Nigel _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-01-13 8:42 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <2097834991.1721031263351861134.JavaMail.root@mail-au.aconex.com>
2010-01-13 3:09 ` [TuxOnIce-devel] Latest updates Nathan Scott
2010-01-13 5:41 ` Dave Chinner
2010-01-13 6:05 ` Nathan Scott
2010-01-13 6:57 ` Dave Chinner
2010-01-13 8:11 ` Dave Chinner
2010-01-13 8:44 ` Nigel Cunningham
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox