From: Dave Chinner <david@fromorbit.com>
To: Nathan Scott <nscott@aconex.com>
Cc: TuxOnIce Devel List <tuxonice-devel@lists.tuxonice.net>, xfs@oss.sgi.com
Subject: Re: [TuxOnIce-devel] Latest updates.
Date: Wed, 13 Jan 2010 16:41:52 +1100 [thread overview]
Message-ID: <20100113054152.GL17483@discord.disaster> (raw)
In-Reply-To: <643097034.1721341263352154340.JavaMail.root@mail-au.aconex.com>
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
next prev parent reply other threads:[~2010-01-13 5:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100113054152.GL17483@discord.disaster \
--to=david@fromorbit.com \
--cc=nscott@aconex.com \
--cc=tuxonice-devel@lists.tuxonice.net \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox