ctime/mtime update in affs and hpfs write path

ctime/mtime update in affs and hpfs write path

[Christoph Hellwig]

Both AFFS and HPFS update the ctime and mtime in the write path, after
generic_file_write returned and mark the inode dirty.  Anyone's got an
idea why these two filesystems aren't happy with the ctime/mtime updates
vi generic_file_write before we copied the data into the pagecache?

Re: ctime/mtime update in affs and hpfs write path

[Roman Zippel]

Hi,

On Tue, 1 Nov 2005, Christoph Hellwig wrote:

> Both AFFS and HPFS update the ctime and mtime in the write path, after
> generic_file_write returned and mark the inode dirty.  Anyone's got an
> idea why these two filesystems aren't happy with the ctime/mtime updates
> vi generic_file_write before we copied the data into the pagecache?

For affs I don't really know, my best guess is it has been there forever 
and there never was a reason to remove it.

bye, Roman

[PATCH] remove superflous ctime/mtime updates in affs

[Christoph Hellwig]

On Tue, Nov 01, 2005 at 02:03:29AM +0100, Roman Zippel wrote:
> > Both AFFS and HPFS update the ctime and mtime in the write path, after
> > generic_file_write returned and mark the inode dirty.  Anyone's got an
> > idea why these two filesystems aren't happy with the ctime/mtime updates
> > vi generic_file_write before we copied the data into the pagecache?
> 
> For affs I don't really know, my best guess is it has been there forever 
> and there never was a reason to remove it.

Ok, what about the following patch?


Signed-off-by: Christoph Hellwig <hch@lst.de>

Index: linux-2.6/fs/affs/file.c
===================================================================
--- linux-2.6.orig/fs/affs/file.c	2005-10-31 15:44:42.000000000 +0100
+++ linux-2.6/fs/affs/file.c	2005-10-31 17:25:26.000000000 +0100
@@ -22,14 +22,13 @@
 static struct buffer_head *affs_alloc_extblock(struct inode *inode, struct buffer_head *bh, u32 ext);
 static inline struct buffer_head *affs_get_extblock(struct inode *inode, u32 ext);
 static struct buffer_head *affs_get_extblock_slow(struct inode *inode, u32 ext);
-static ssize_t affs_file_write(struct file *filp, const char __user *buf, size_t count, loff_t *ppos);
 static int affs_file_open(struct inode *inode, struct file *filp);
 static int affs_file_release(struct inode *inode, struct file *filp);
 
 struct file_operations affs_file_operations = {
 	.llseek		= generic_file_llseek,
 	.read		= generic_file_read,
-	.write		= affs_file_write,
+	.write		= generic_file_write,
 	.mmap		= generic_file_mmap,
 	.open		= affs_file_open,
 	.release	= affs_file_release,
@@ -473,21 +472,6 @@
 	return ERR_PTR(err);
 }
 
-static ssize_t
-affs_file_write(struct file *file, const char __user *buf,
-		size_t count, loff_t *ppos)
-{
-	ssize_t retval;
-
-	retval = generic_file_write (file, buf, count, ppos);
-	if (retval >0) {
-		struct inode *inode = file->f_dentry->d_inode;
-		inode->i_ctime = inode->i_mtime = CURRENT_TIME_SEC;
-		mark_inode_dirty(inode);
-	}
-	return retval;
-}
-
 static int
 affs_do_readpage_ofs(struct file *file, struct page *page, unsigned from, unsigned to)
 {

Re: [PATCH] remove superflous ctime/mtime updates in affs

[Roman Zippel]

Hi,

On Tue, 1 Nov 2005, Christoph Hellwig wrote:

> > For affs I don't really know, my best guess is it has been there forever 
> > and there never was a reason to remove it.
> 
> Ok, what about the following patch?
> 
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Acked-by: Roman Zippel <zippel@linux-m68k.org>

bye, Roman

Re: ctime/mtime update in affs and hpfs write path

[Mikulas Patocka]

On Tue, 1 Nov 2005, Christoph Hellwig wrote:

> Both AFFS and HPFS update the ctime and mtime in the write path, after
> generic_file_write returned and mark the inode dirty.  Anyone's got an
> idea why these two filesystems aren't happy with the ctime/mtime updates
> vi generic_file_write before we copied the data into the pagecache?

In HPFS, there's no reason for mtime update --- just that it was left when 
porting code from older kernels. If generic_file_write updates it, you can 
remove update in HPFS.

As for inode dirty --- HPFS has its own dirty mechanism different from the 
kernel to avoid deadlocks (writing inode on HPFS needs to lock parent 
directory and you can't do it from ->write_inode method) --- let it be, it 
may be slower, but it's stable.

Mikulas