Skip to contentSkip to conversation

Loopback mounts should update the mtime of the underlying file on writes

PATCH In review Matt Mackall 2 participants 3 messages Nov 6, 2007 Block layer

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Loopback mounts should update the mtime of the underlying file on writes

Noticed by a Mercurial user. I think this should fix it.

drivers/block/loop.c +2 -0
Index: l/drivers/block/loop.c
===================================================================
@@ -221,6 +221,7 @@ static int do_lo_send_aops(struct loop_d
 	offset = pos & ((pgoff_t)PAGE_CACHE_SIZE - 1);
 	bv_offs = bvec->bv_offset;
 	len = bvec->bv_len;
+	file_update_time(file);
 	while (len > 0) {
 		sector_t IV;
 		unsigned size;
@@ -299,6 +300,7 @@ static int __do_lo_send_write(struct fil
 
 	set_fs(get_ds());
 	bw = file->f_op->write(file, buf, len, &pos);
+	file_update_time(file);
 	set_fs(old_fs);
 	if (likely(bw == len))
 		return 0;
Signature · 1 line
Mathematics is the supreme nostalgia of our time.
#1 lore raw
Quoted 2 lines · On Mon, 5 Nov 2007 19:09:24 -0600 Matt Mackall <[email protected]> wrote:

Noticed by a Mercurial user. I think this should fix it.

"should". That pitter patter sound your hear is little akpm feet running away.

Quoted 14 lines

Index: l/drivers/block/loop.c
===================================================================

drivers/block/loop.c +1 -0
@@ -221,6 +221,7 @@ static int do_lo_send_aops(struct loop_d
 	offset = pos & ((pgoff_t)PAGE_CACHE_SIZE - 1);
 	bv_offs = bvec->bv_offset;
 	len = bvec->bv_len;
+	file_update_time(file);
 	while (len > 0) {
 		sector_t IV;
 		unsigned size;

drivers/block/loop.c static int __do_lo_send_write(struct fil · line 306

Quoted 7 lines
drivers/block/loop.c +1 -0
@@ -299,6 +300,7 @@ static int __do_lo_send_write(struct fil
 
 	set_fs(get_ds());
 	bw = file->f_op->write(file, buf, len, &pos);
+	file_update_time(file);
 	set_fs(old_fs);
 	if (likely(bw == len))
 		return 0;

Probably makes sense, but bear in mind that we can be fairly deep in filesystem A functions here, and file_update_time() can do stuff like starting journal transactions on filesystem B.

I expect the worst we'll see is not-yet-suppressed lockdep warnings and possibly extra stack windup, but this patch may end up being more complex than one expects..

#2 lore raw
Quoted 7 lines · Andrew Morton
Quoted 2 lines · On Mon, 5 Nov 2007 19:09:24 -0600 Matt Mackall <[email protected]> wrote:

Noticed by a Mercurial user. I think this should fix it.

"should". That pitter patter sound your hear is little akpm feet running away.

Well I did actually test it.

Quoted 14 lines
Quoted 14 lines

Index: l/drivers/block/loop.c
===================================================================

drivers/block/loop.c +1 -0
@@ -221,6 +221,7 @@ static int do_lo_send_aops(struct loop_d
 	offset = pos & ((pgoff_t)PAGE_CACHE_SIZE - 1);
 	bv_offs = bvec->bv_offset;
 	len = bvec->bv_len;
+	file_update_time(file);
 	while (len > 0) {
 		sector_t IV;
 		unsigned size;
@@ -299,6 +300,7 @@ static int __do_lo_send_write(struct fil
 
Quoted 10 lines

drivers/block/loop.c static int __do_lo_send_write(struct fil · line 306

Quoted 6 lines
drivers/block/loop.c +1 -0
 	set_fs(get_ds());
 	bw = file->f_op->write(file, buf, len, &pos);
+	file_update_time(file);
 	set_fs(old_fs);
 	if (likely(bw == len))
 		return 0;

Probably makes sense, but bear in mind that we can be fairly deep in filesystem A functions here, and file_update_time() can do stuff like starting journal transactions on filesystem B.

I think that can alread happen, no? Especially if we're filling in holes.

Signature · 1 line
Mathematics is the supreme nostalgia of our time.