Re: s2disk and raid

[Tim Dijkstra <newsuser@famdijkstra.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3371 bytes --]

On Wed, 4 Apr 2007 15:20:56 +1000
Neil Brown <neilb@suse.de> wrote:

> On Tuesday April 3, newsuser@famdijkstra.org wrote:
> > Hi,
> > 
> > I've got a bugreport [0] from a user trying to use raid and uswsusp. He's
> > using initramfs-tools available in debian. I'll describe the problem
> > and my analysis, maybe you can comment on what you think. A warning: I only
> > have a casual understanding of raid, never looked at any code related to it.
> > 
> > This is a setup where root maybe on raid, but swap isn't. Swap on raid
> > will be very difficult to support, I think.
> 
> Nah... shouldn't be a problem.... well, maybe raid5.

OK, that is nice to hear.

> > 
> > When s2disk is started, nothing special is done to the array. It may be
> > in an unclean state (just like filesystems). Image is written to disk.
> > 
> > After the power cycle the kernel boots, devices are discovered, among
> > which the ones holding raid. Then we try to find the device that holds
> > swap in case of resume and / in case of a normal boot.
> > 
> > Now comes a crucial point. The script that finds the raid array, finds
> > the array in an unclean state and starts syncing.
> 
> Uhm, so you are finding the device for the root filesystem before you
> have decided which case it will be (resume or normal boot).  Can that
> be delayed until after the decision.  It's probably not important but
> it seems neater.
> Or do you need the root device even when resuming (I guess if swap is
> in a file on the root filesystem....)

It is not that we need the root filesystem for resume. It is more how
the initramfs is currently setup. To be as general as possible, all
partitions are discoverd, of which one will contain the image.

> The trick is to use the 'start_ro' module parameter.
>   echo 1 > /sys/module/md_mod/parameters/start_ro
> 
> Then md will start arrays assuming read-only.  No resync will be
> started, no superblock will be written.  They stay this way until the
> first write at which point they become normal read-write and any
> required resync starts.
> 
> So you can start arrays 'readonly', and resume off a raid1 without any
> risk of the the resync starting when it shouldn't.
> 
> It is probably best to 'echo 0 > ....' once you have committed to a
> normal boot, but it isn't really critical.

This is very good to know. I think we can work out something with the
debian-maintainer based on this.

> > 
> > The debian-maintainer of mdadm thinks that the suspend process should
> > have left the array in a clean state, but this is IMHO impossible.
> 
> It probably would be best if suspend left the process in a clean
> state.  It shouldn't be too hard, but it needs to be done in the
> kernel.
> However it isn't critical to all of this working well.
> 
> I mentioned above that if swap in on raid5 it might be awkward.  This
> is because raid5 caches some data that is on disk.  If you snapshot
> the raid5 memory, then resume raid5 so it can write to disk, when you
> come back from suspend you could have old data in the cache.  It
> should be possible to fix this, but it is currently a potential
> problem that might be worth warning people against.

OK, if we can support suspend and raid and even with swap on raid0 or
raid1, I'm happy.

Thanks for the input.

grts Tim

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel