From: Nigel Cunningham <ncunningham@crca.org.au>
To: Dave Chinner <david@fromorbit.com>
Cc: TuxOnIce Devel List <tuxonice-devel@lists.tuxonice.net>,
Nathan Scott <nscott@aconex.com>,
xfs@oss.sgi.com
Subject: Re: [TuxOnIce-devel] Latest updates.
Date: Wed, 13 Jan 2010 19:44:08 +1100 [thread overview]
Message-ID: <4B4D87D8.5050900@crca.org.au> (raw)
In-Reply-To: <20100113081140.GO17483@discord.disaster>
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
prev parent reply other threads:[~2010-01-13 8:42 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
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 message]
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=4B4D87D8.5050900@crca.org.au \
--to=ncunningham@crca.org.au \
--cc=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