Message-ID: <20150120112137.GC15756@quack.suse.cz>
Date:	Tue, 20 Jan 2015 12:21:37 +0100
From:	Jan Kara <jack@...e.cz>
To:	Namjae Jeon <namjae.jeon@...sung.com>
Cc:	'Dave Chinner' <david@...morbit.com>,
	'Theodore Ts'o' <tytso@....edu>,
	'Alexander Viro' <viro@...iv.linux.org.uk>,
	'Brian Foster' <bfoster@...hat.com>,
	'Dmitry Monakhov' <dmonakhov@...nvz.org>,
	'Lukáš Czerner' <lczerner@...hat.com>,
	linux-fsdevel@...r.kernel.org,
	'Ashish Sangwan' <a.sangwan@...sung.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] fs: file freeze support

On Mon 19-01-15 22:07:01, Namjae Jeon wrote:
> > > When this state is set, any process which tries to modify the file's address
> > > space, either by pagefault mmap writes or using write(2), will block until
> > > the this state is cleared. I_WRITE_FREEZED is set by calling FS_IOC_FWFREEZE
> > > ioctl and clear by FS_IOC_FWTHAW ioctl.
> > >
> > > File write freeze functionality, when used in conjunction with
> > > inode's immutable flag can be used for creating truly stable file snapshots
> > > wherein write freeze will prevent any modification to the file from already
> > > open file descriptors and immutable flag will prevent any new modification
> > > to the file. One of the intended uses for stable file snapshots would be in
> > > the defragmentation applications which defrags single file.
> > 
> > I don't quite understand why the full filesystem freeze is
> > necessary? The thaw occurs immediately after I_WRITE_FREEZED is set,
> We started by looking at fs freeze for file freeze implementation,
> So got biased for using fs freeze or similar approach.
> Thanks for suggesting a better way.
> 
> > which means there's nothing that prevent the file from being
> > truncated or otherwise modified by fallocate, etc while it is
> > frozen....
> Right, So, After that, we had also thought of setting immutable
> flag of inode. Immutable flag + I_WRITE_FROZEN => truly frozen file.
> 
> > 
> > AFAICT, fsync will bring the file down to a consistent state and
> > we've already got freeze hooks for all inode modification
> > operations. We also have IO barriers for truncate operations so that
> > we can wait for all outstanding IO to complete, so I would have
> > thought this covers all bases for an inode freeze. i.e.:
> Right.
> 
> > 
> > i_mutex -> I_FROZEN -> fsync -> inode_dio_wait
> > 
> > Should give us a clean inode where there are not ongoing operations
> > by the time that inode_dio_wait() completes. All new modification
> > operations need to check I_FROZEN in addition to the superblock
> > freeze checks...
> I checked the routines where checks for I_FROZEN would be required.
> Most of them are Ok but do_unlinkat() confuses me a little.
> vfs_unlink is called under parent inode's i_mutex, so we cannot sleep
> keeping parent's i_mutex held.
> i.e while freezing file, all file in directory are blocked by parent
> i_mutex. Is it ok to release parnets->mutex before checking for I_FROZEN
> or there is some idea?
  So I believe Dave thought that you'd just reuse places we currently use
to call sb_start_write() / mnt_want_write(). You'd probably have to come up
with a function like path_want_write() (takes struct path as an argument)
and which will call mnt_want_write(), sb_start_write(), and do appropriate
inode freeze handling. Then you replace all calls to mnt_want_write() with
calls to path_want_write()... Possibly you can also provide a trivial
wrapper for path_want_write() which takes struct file instead.

This should also deal with the locking problems you describe above as
mnt_want_write() is always called before taking i_mutex.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists