Re: [PATCH 2.6.19 5/5] fs: freeze_bdev with semaphore not mutex

[Nigel Cunningham <nigel@suspend2.net>]

Hi.

On Wed, 2006-11-08 at 13:10 +0100, Rafael J. Wysocki wrote:
> On Wednesday, 8 November 2006 03:30, Alasdair G Kergon wrote:
> > On Tue, Nov 07, 2006 at 11:49:51PM +0000, Alasdair G Kergon wrote:
> > > I hadn't noticed that -mm patch.  I'll take a look.  
> > 
> > swsusp-freeze-filesystems-during-suspend-rev-2.patch
> > 
> > I think you need to give more thought to device-mapper
> > interactions here.  If an underlying device is suspended
> > by device-mapper without freezing the filesystem (the
> > normal state) and you issue a freeze_bdev on a device
> > above it, the freeze_bdev may never return if it attempts
> > any synchronous I/O (as it should).
> 
> Well, it looks like the interactions with dm add quite a bit of
> complexity here.
> 
> > Try:
> >   while process generating I/O to filesystem on LVM
> >   issue dmsetup suspend --nolockfs (which the lvm2 tools often do)
> >   try your freeze_filesystems()
> 
> Okay, I will.
> 
> > Maybe: don't allow freeze_filesystems() to run when the system is in that
> > state;
> 
> I'd like to avoid that (we may be running out of battery power at this point).
> 
> > or, use device-mapper suspend instead of freeze_bdev directly where 
> > dm is involved;
> 
> How do I check if dm is involved?
> 
> > or skip dm devices that are already frozen - all with 
> > appropriate dependency tracking to process devices in the right order.
> 
> I'd prefer this one, but probably the previous one is simpler to start with.

Shouldn't we just go for the right thing to begin with? Otherwise we'll
just make more problems for ourselves later.

If we do this last one, I guess we want to do something like I was doing
before (creating a list of the devices we've frozen)?

Regards,

Nigel