Skip to contentSkip to conversation

generic/059: also test that the file's mtime and ctime are updated

PATCH In review [email protected] 2 participants 4 messages Jun 19, 2019 – Jun 21, 2019 Btrfs file system

lore
Share & tools
lore
#0 lore raw

PATCH 2/2 generic/059: also test that the file's mtime and ctime are updated

From: Filipe Manana <[email protected]>

Test as well that hole punch operations that affect a single file block also update the file's mtime and ctime.

This is motivated by a bug a found in btrfs which is fixed by the following patch for the linux kernel:

"Btrfs: add missing inode version, ctime and mtime updates when
punching hole"

---
 tests/generic/059 | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
tests/generic/059 +18 -0
index e8cb93d8..fd44b2ea 100755
@@ -18,6 +18,9 @@
 #
 #  Btrfs: add missing inode update when punching hole
 #
+# Also test the mtime and ctime properties of the file change after punching
+# holes with ranges that operate only on a single block of the file.
+#
 seq=`basename $0`
 seqres=$RESULT_DIR/$seq
 echo "QA output created by $seq"
@@ -68,6 +71,13 @@ $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo
 # fsync log.
 sync
 
+# Sleep for 1 second, because we want to check that the next punch operations we
+# do update the file's mtime and ctime.
+sleep 1
+
+mtime_before=$(stat -c %Y $SCRATCH_MNT/foo)
+ctime_before=$(stat -c %Z $SCRATCH_MNT/foo)
+
 # Punch a hole in our file. This small range affects only 1 page.
 # This made the btrfs hole punching implementation write only some zeroes in
 # one page, but it did not update the btrfs inode fields used to determine if
@@ -94,5 +104,13 @@ _flakey_drop_and_remount
 echo "File content after:"
 od -t x1 $SCRATCH_MNT/foo
 
+mtime_after=$(stat -c %Y $SCRATCH_MNT/foo)
+ctime_after=$(stat -c %Z $SCRATCH_MNT/foo)
+
+[ $mtime_after -gt $mtime_before ] || \
+	echo "mtime did not increase (before: $mtime_before after: $mtime_after"
+[ $ctime_after -gt $ctime_before ] || \
+	echo "ctime did not increase (before: $ctime_before after: $mtime_after"
+
 status=0
 exit
Signature · 1 line
2.11.0
#1 lore raw
Quoted 31 lines · On Wed, Jun 19, 2019 at 01:06:24PM +0100, [email protected] wrote:

From: Filipe Manana <[email protected]>

Test as well that hole punch operations that affect a single file block also update the file's mtime and ctime.

This is motivated by a bug a found in btrfs which is fixed by the following patch for the linux kernel:

"Btrfs: add missing inode version, ctime and mtime updates when
punching hole"

---
 tests/generic/059 | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
tests/generic/059 +3 -0
index e8cb93d8..fd44b2ea 100755
@@ -18,6 +18,9 @@
 #
 #  Btrfs: add missing inode update when punching hole
 #
+# Also test the mtime and ctime properties of the file change after punching
+# holes with ranges that operate only on a single block of the file.
+#
 seq=`basename $0`
 seqres=$RESULT_DIR/$seq
 echo "QA output created by $seq"

tests/generic/059 $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo · line 76

Quoted 6 lines
tests/generic/059 +3 -0
@@ -68,6 +71,13 @@ $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo
 # fsync log.
 sync
 
+# Sleep for 1 second, because we want to check that the next punch operations we
+# do update the file's mtime and ctime.
+sleep 1

Is this supposed to be after recording the initial c/mtime? i.e. moving it after c/mtime_before?

Thanks,
Eryu

Quoted 24 lines
tests/generic/059 +12 -0
+
+mtime_before=$(stat -c %Y $SCRATCH_MNT/foo)
+ctime_before=$(stat -c %Z $SCRATCH_MNT/foo)
+
 # Punch a hole in our file. This small range affects only 1 page.
 # This made the btrfs hole punching implementation write only some zeroes in
 # one page, but it did not update the btrfs inode fields used to determine if
@@ -94,5 +104,13 @@ _flakey_drop_and_remount
 echo "File content after:"
 od -t x1 $SCRATCH_MNT/foo
 
+mtime_after=$(stat -c %Y $SCRATCH_MNT/foo)
+ctime_after=$(stat -c %Z $SCRATCH_MNT/foo)
+
+[ $mtime_after -gt $mtime_before ] || \
+	echo "mtime did not increase (before: $mtime_before after: $mtime_after"
+[ $ctime_after -gt $ctime_before ] || \
+	echo "ctime did not increase (before: $ctime_before after: $mtime_after"
+
 status=0
 exit
Signature · 1 line
2.11.0
#2 lore raw
Quoted 36 lines · Eryu Guan
Quoted 34 lines · On Wed, Jun 19, 2019 at 01:06:24PM +0100, [email protected] wrote:

From: Filipe Manana <[email protected]>

Test as well that hole punch operations that affect a single file block also update the file's mtime and ctime.

This is motivated by a bug a found in btrfs which is fixed by the following patch for the linux kernel:

"Btrfs: add missing inode version, ctime and mtime updates when
punching hole"

---
 tests/generic/059 | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
tests/generic/059 +3 -0
index e8cb93d8..fd44b2ea 100755
@@ -18,6 +18,9 @@
 #
 #  Btrfs: add missing inode update when punching hole
 #
+# Also test the mtime and ctime properties of the file change after punching
+# holes with ranges that operate only on a single block of the file.
+#
 seq=`basename $0`
 seqres=$RESULT_DIR/$seq
 echo "QA output created by $seq"
@@ -68,6 +71,13 @@ $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo
 # fsync log.
 sync
 
Quoted 6 lines

tests/generic/059 $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo · line 76

Quoted 3 lines
tests/generic/059 +3 -0
+# Sleep for 1 second, because we want to check that the next punch operations we
+# do update the file's mtime and ctime.
+sleep 1

Is this supposed to be after recording the initial c/mtime? i.e. moving it after c/mtime_before?

Either way is fine. Capturing the times right before or right after the sleep, gives the same values as nothing changed the file.

Btw, I had noticed the other day that the second "echo" has $mtime_after instead of $ctime_after (copy-paste mistake). Do you want me to send a v2 fixing that typo, or you can do it yourself when you pick the patch?

Thanks.

Quoted 28 lines

Thanks,
Eryu

Quoted 24 lines
tests/generic/059 +12 -1
+
+mtime_before=$(stat -c %Y $SCRATCH_MNT/foo)
+ctime_before=$(stat -c %Z $SCRATCH_MNT/foo)
+
 # Punch a hole in our file. This small range affects only 1 page.
 # This made the btrfs hole punching implementation write only some zeroes in
 # one page, but it did not update the btrfs inode fields used to determine if
@@ -94,5 +104,13 @@ _flakey_drop_and_remount
 echo "File content after:"
 od -t x1 $SCRATCH_MNT/foo
 
+mtime_after=$(stat -c %Y $SCRATCH_MNT/foo)
+ctime_after=$(stat -c %Z $SCRATCH_MNT/foo)
+
+[ $mtime_after -gt $mtime_before ] || \
+     echo "mtime did not increase (before: $mtime_before after: $mtime_after"
+[ $ctime_after -gt $ctime_before ] || \
+     echo "ctime did not increase (before: $ctime_before after: $mtime_after"
+
 status=0
 exit
--

2.11.0

#3 lore raw
Quoted 44 lines · Filipe Manana
Quoted 36 lines · Eryu Guan
Quoted 34 lines · On Wed, Jun 19, 2019 at 01:06:24PM +0100, [email protected] wrote:

From: Filipe Manana <[email protected]>

Test as well that hole punch operations that affect a single file block also update the file's mtime and ctime.

This is motivated by a bug a found in btrfs which is fixed by the following patch for the linux kernel:

"Btrfs: add missing inode version, ctime and mtime updates when
punching hole"

---
 tests/generic/059 | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
tests/generic/059 +3 -0
index e8cb93d8..fd44b2ea 100755
@@ -18,6 +18,9 @@
 #
 #  Btrfs: add missing inode update when punching hole
 #
+# Also test the mtime and ctime properties of the file change after punching
+# holes with ranges that operate only on a single block of the file.
+#
 seq=`basename $0`
 seqres=$RESULT_DIR/$seq
 echo "QA output created by $seq"
@@ -68,6 +71,13 @@ $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo
 # fsync log.
 sync
 
Quoted 6 lines

tests/generic/059 $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo · line 76

Quoted 3 lines
tests/generic/059 +3 -0
+# Sleep for 1 second, because we want to check that the next punch operations we
+# do update the file's mtime and ctime.
+sleep 1

Is this supposed to be after recording the initial c/mtime? i.e. moving it after c/mtime_before?

Quoted 2 lines

Either way is fine. Capturing the times right before or right after the sleep, gives the same values as nothing changed the file.

Ah, you're right.

Quoted 5 lines

Btw, I had noticed the other day that the second "echo" has $mtime_after instead of $ctime_after (copy-paste mistake). Do you want me to send a v2 fixing that typo, or you can do it yourself when you pick the patch?

I can fix it on commit, thanks for pointing it out!

Thanks,
Eryu