[Ksummit-discuss] [TECH TOPIC] giving freezer well-defined semantics

Jan Kara jack at suse.cz
Thu Jul 9 11:25:10 UTC 2015


On Wed 08-07-15 23:55:09, Rafael J. Wysocki wrote:
> On Wednesday, July 08, 2015 10:16:39 AM Jiri Kosina wrote:
> > On Wed, 8 Jul 2015, Rafael J. Wysocki wrote:
> > 
> > > OK, it is necessary to ensure that the contents of the image will be 
> > > consistent with the state of filesystems on the storage media, so 
> > > everything that may change that state should be "frozen" before the 
> > > image is created, but "frozen" in terms of "no persistent state changes 
> > > from now on" rather than in terms of "no forward progress from now on".
> > 
> > Yeah. So again, why do we even have freezer for so many kernel threads at 
> > all? :)
> 
> Well, one reason may be that we've never grown a decent mechanism for freezing
> filesystems (as in "no persistent state changes from now on") and people try to
> make up for that by stopping things if they can (but in the kernel space that's
> inherently racy).

The most common filesystems - xfs, ext4, ext3, btrfs - handle freezing fine
these days. And the filesystem freezing is used by LVM snapshots,
Virtualization guest snapshots etc. so it is even tested ;).

I know you have proposed to use fs freezing during hibernation some time
ago but I don't remember where it ended up... Do you remember?

								Honza
-- 
Jan Kara <jack at suse.cz>
SUSE Labs, CR


More information about the Ksummit-discuss mailing list